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(Block  20  continued’^  p.  I j 

~y  capabilities  of  that  software  to  extract  data  from  distributed  data 
^ bases  on  non-homogeneous  computers  at  geographically  dispersed  sites.  | 
The  major  technical  Interests  and  contributions  of  the  project  aret ' : 

• a distributed  Data  Directory  concept;  ! 

• ^ 'generalized^  parameter-driven  data  base  interface  ■ 1 

• -a  synonym  resolution  capability  >'■>-  j 

•:  a secondary  *'hit*  resolution  capability.  '■ 

The  major  recommendatlons-^orwarded  in  section  8.2^of  th4  report  are?  ^ 

-that  NAVLIS  technology  be  reviewed  for  its  relevance  to  on-going 
(_  university  level  projects 

NAVLIS  technology  be  considered  for  its  potential  benefits  to 
other  logistics  system  developments,  such  as  WWMICS  and  NAICOMMIS^  ■ 

J -that  consideration  be  given  to  utilizing  the  NAVLIS  technology  in 
/ networking  the  Navy  Data  Processing  Service  Centers, . 


Appendix  A of  this  report  contains  Che  individual  software  program  docu- 
mentation and  logic  charts  comprising  the  NAVLIS  Executive  Subsystem 
Documentation.  (The  NAVLIS  Pilot  Model  Software  consisted  of  two  sub- 
systems, (1)  the  Executive  Subsystem,  and  (2)  Telecommunications 
Subsystem  (NTS)). 

Appendix  B of  this  report  describes  the  NAVLIS  effort  for  the  Commander 
in  Chief,  Atlantic  Fleet  (CINCLANTFLT)  which  was  on-going  at  project 
termination.  The  report,  in  the  form  of  a Case  Study,  describes  the 
application,  which  was  to  assist  the  Atlantic  Fleet  in  its  ship  over- 
haul scheduling  and  funding  and  to  provide  an  interactive  data  base  as 
a management  tool  for  the  CINCLANTFLT  staff. 
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1.  INTRODUCTION 


The  Navy  Logistics  Information  Sharing  (NAVLIS)  project  is  a 
Navy  RDT&E  program  in  the  advanced  development  (6.3)  phase.  The 
objective  of  the  project  v;as  to  develop  and  demonstrate  a capability 
to  provide  Navy  Managers  with  accurate,  controlled,  and  timely 
logistics  data  and  information  by  applying  computer  networking  and 
data  base  sharing  to  existing  and  planned  Naval  Logistics  Automated 
Data  Processing  (ADP)  systems. 

The  technology  presented  in  this  report  represents  2-1/2  years 
of  extensive  effort  by  a team  of  analysts  and  programmers  at  DTNSRDC 
and  other  Navy  Installations.  This  report  describes  and  discusses 
the  NAVLIS  project  status  at  its  termination  by  its  sponsors  in 
December  1976. 


1.1  BACKGROUND  AND  PURPOSE  OF  REPORT 


In  January  1973,  The  Chief  of  Naval  Material  (CHNAVMAT)  advised 
the  Commander,  Naval  Electronics  Laboratory  Center  (NELC)  and  the 
Commander,  David  W.  Taylor  Naval  Ship  Research  and  Development  Center 
(DTNSRDC)  that: 

"...to  centralize  the  R&D  support  of  Navy  Logistics... 
it  is  desired  to  reassign  the  technical  management  of 
NAVLIS  (Navy  Logistic  Information  Sharing)  from  NELC 
to  DTNSRDC." 

A NAVLIS  study  team  was  established  in  the  DTNSRDC  Computation 
and  Mathematics  Department  to  accomplish  the  transfer  of  the  project 
from  NELC.  Tne  mission  of  the  team  was  established  as  follows: 

a.  Review  the  requirements  and  objectives  of  NAVLIS 

as  stated  in  source  documents  in  relation  to  current 
logistics  information  requirements. 

b.  Evaluate  the  progress  achieved  by  the  NAVLIS  Program 
to  date. 

c.  Assess  current  efforts  from  the  standpoint  of  their 
potential  for  resolving  technological  and  operational 
problems. 

d.  Formulate  a DTNSRDC  management  plan  for  NAVLIS. 

The  DTNSRDC  evaluation  listed  the  following  general  findings: 

a.  The  NAVLIS  development  program  had  fallen  short  of 
the  goals  spelled  out  in  the  requirements  documents. 

A system  Initial  Operational  Capability  (IOC)  in 
FY75  was  not  attainable. 

b.  The  NAVLIS  development  effort  now  differed  markedly 
from  that  proposed  in  the  Proposed  Technical  Approaches 
(PTA)  and  set  forth  as  a requirement  in  the  Advanced 
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Development  Objective  (ADO).  Emphasis  had  shifted 
from  system  development  to  development  of  an  infor- 
mation sharing  capability. 

c.  Neither  the  reduction  in  program  objective  nor  the 
shift  in  development  emphasis  had  been  formally 
documented. 

d.  The  original  requirement  for  improvements  in  Navy 
Logistics  information  management  still  existed. 

This  report,  representing  the  final  documentation  of  the  NAVLIS 
project,  identifies  significant  findings,  and  formulates  recommendations 
and  potential  applications. 

1.2  PROJECT  HISTORY  AND  FUNDING  PROFILE 

The  NAVLIS  program  began  with  the  issuance  of  a Tentative  Specific 
Operational  Requirement  (TSOR  41-12T)  iri  December  1967,  but  was  first 
funded  as  a 6.3  program  in  Fiscal  Year  69.  The  NAVLIS  Advanced  Develop- 
ment Objectives  (ADO  41-12X)  was  issued  in  December  1969.  The  OPNAV 
sponsor  for  NAVLIS  is  OP-04.  The  Principal  Development  Activity  (PDA) 
is  the  Chief  of  Naval  Material  with  specific  responsibility  assigned  to 
MAT  034.  The  lead  laboratory  function  was  transferred  from  Naval 
Electronic  Laboratory  Center  (NELC)  to  David  W.  Taylor  Naval  Ship 
Research  and  Development  Center  (DTNSRDC)  in  February  1973. 

The  NAVLIS  TSOR,  Proposed  Technical  Approaches  (PTA  41-12T),  ADO, 
and  Project  Management  Plan  (PMP)  were  issued  prior  to  Calendar  Year 
1970.  These  documents  were  directed  toward  development  and  implementation 
of  a large.  Navy-wide,  logistics  information  system.  This  system,  as 
originally  envisioned,  had  a dedicated  management  and  operations  staff, 
unique  supporting  hardware  and  communications,  and  unique  and  highly 
sophisticated  software.  Development  funds  were  estimated  at  $19. 7M 
in  the  PTA  and  $15M  in  the  ADO  to  bring  the  system  to  Initial  Operational 
Capability  (IOC)  in  FY75. 
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Actual  funding  for  NAVLIS  is  shown  in  Figure  1.  Total  funding 
through  FY75  was  $3.07M  or  approximately  20%  of  the  ADO  plan.  Funding 
in  FY70  and  FY72  was  zero. 

Working  level  responsibility  as  PDA  has  been  assigned  to  four 
different  groups  within  the  Naval  Material  Command  since  1968,  and 
technical  responsibility  to  two  different  Navy  laboratories  since  1970. 
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2.  EXECUTIVE  SUMMARY  AND  CONCLUSIONS 


The  objectives  of  the  NAVLIS  project  as  stated  in  the  Technical 
Development  Plan  (TDP  41-12X,  15  April  1974)  were  to  "Investigate 
feasibility  and  desirability  of  applying  developments  in  distributed 
data  base  management  systems  and  computer  networks  to  resolution  of 
problems  with  logistics  information  and  Navy  logistics  automated  data 
systems,  e.g.,  lack  of  flexible  response  to  ad  hoc  queries;  multiple 
input,  storage  and  update  of  data  elements;  proliferation  of  single 
purpose,  limited  access,  non-standard  information  systems;  and  limited 
automated  data  transfer  capability  between  systems."  In  the  process 
of  that  investigation,  a NAVLIS  baseline  system  concept  was  developed 
and  demonstrated  in  a commercial  teleprocessing  and  computing  environ- 
ment. The  baseline  concept  was  expanded  and  implemented  as  a NAVLIS 
Pilot  Model  (See  Figure  2)  in  an  operational  Navy  data  processing 
environment.  At  project  termination,  the  Pilot  Model  consisted  of  a 
dial-up  communication  capability  connecting  a terminal  user  with  two 
remote  data  processing  facilities:  a UNIVAC  Spectra  70/45  at  the  Data 

Processing  Service  Center  for  the  Pacific  (DPSCPAC)  in  San  Diego,  Calif, 
and  an  IBM  360/65  or  370/165  at  the  Naval  Material  Command  Support 
Activity  (NMCSA)  in  Arlington,  Virginia.  It  provided  ad  hoc  query 
capability  to  two  logistics  data  bases:  the  Aircraft  Power  Plant 

Management  System  (APPMS)  at  DPSCPAC  and  the  Aircraft  Engines  Account- 
ing (AEA)  System  at  NMCSA. 

This  section  will  address  the  areas  of  "feasibility  and  desirabil ity" 
of  a NAVLIS-type  capability  as  well  as  questions  of  practicability, 
sponsorship,  and  implementation.  The  conclusions  presented  here  are 
based  on  the  experience  gained  during  concept  formulation  and  Pilot/Model 
development. 

In  discussing  the  feasibility  of  a NAVLIS-Lype  system,  technical 
feasibility  must  be  separated  from  administrative  or  organizational 
feasibility.  No  new  technological  developments  were  required  for  the 
development  and  implementation  of  the  Pilot  Model  and  no  requirement 
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for  any  unavailable  technological  features  was  identified  when  consider- 
ing the  progression  from  a Pilot  Model  to  an  operational  system.  All 
the  software  was  coded  in  COBOL  or  Assembler  language  and  the  hardware 
procured  for  on-line  storage  and  telecommunications  consisted  of  off-the- 
shelf  items. 

Given  the  concurrent  commercial  progress  in  nrtworking,  data  manage- 
ment systems,  and  distributed  processing,  the  NAVLIS  concept  continuously 
becomes  both  more  feasible  and  more  practical.  Commercial  and  Federally 
funded  efforts  to  network  nonhomogeneous  computers  for  distributed 
processing  and  data  base  transfer  are  currently  in  progress.  Recent  and 
continuing  progress  in  the  development  of  mass  storage  devices,  enabling 
on-line  access  to  very  large  data  bases,  contributes  significantly  to 
the  practicality  of  a NAVLIS  system.  In  NAVLIS  infancy,  these  develop- 
ments were  state-of-the-art  and  beyond.  The  project,  however,  was 
originally  intended  to  utilize  the  capabilities  of  the  late  1970's. 

The  NAVLIS  objective  of  networking  remote,  nonhomogeneous  computers  for 
simultaneous  access  to  multiple,  on-line,  nonstandard  data  bases  in 
response  to  a user's  query  represents  the  consolidation  of  these  capa- 
bilities applied  to  the  Navy  logistics  problem. 

These  capabilities  were  utilized  in  a new  direction  for  NAVLIS, 
i.e.,  different  computers  were  required  to  communicate,  for  the  purpose 
of  data  retrieval  rather  than  process  sharing.  The  data  retrieval  was 
performed  on  a data  element  basis,  rather  than  through  the  transfer  of 
files  as  in  the  ARPA  network.  This  meant  having  data  management  system 
retrieval  and  access  capability  at  multiple  locations.  The  logistics 
data  bases  that  are  candidates  for  a NAVLIS  system  are  all  large,  yet 
on-line  access  is  a requirement  for  acceptable  response  time.  At  project 
termination,  the  Pilot  Model  was  using  disk  storage  and  the  overhead 
was  noticeable.  An  operational  system,  however,  could  justify  and 
would  benefit  considerably  from  the  use  of  mass  storage  devices.  In  short, 
the  NAVLIS  technological  requirements  were  very  much  in  tune  with 
commercial  and  government  software  and  hardware  developments,  and  the 
developments  continue  to  establish  the  practicality  and  technical 
feasibility  of  the  NAVLIS  concept. 
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Feasibility  in  areas  other  than  hardware  and  software  is  an  entirely 
different  matter.  An  especially  difficult  area  concerns  the  individuals 
responsible  for  a data  base  and  its  contents,  and  their  hesitancy  to  make 
their  data  available  to  other  logistics  managers.  The  tendency  is  to 
want  to  "sanitize"  the  data  before  it  leaves  the  responsible  manager's 
jurisdiction.  The  justification  for  this  is  that  often  raw  data  values 
can  be  misleading  if  not  considered  in  conjunction  with  other  values  or 
conditions.  These  additional  values  or  conditions  may  be  represented 
by  other  contents  in  the  data  base,  in  which  case  the  system  can  take 
some  measures  to  see  that  all  relevant  data  are  retrieved  or  that  the 
user  is  advised  that  the  data  retrieved  may  be  incomplete  or  misleading 
(see  Section  7.1.6).  Little  can  be  done,  however,  with  data  that  normally 
gets  manipulated  by  the  local  manager  before  release.  When  the  values 
in  the  data  base  become  meaningful  or  valid  only  when  combined  with 
nonautomated  data,  e.g.,  hardcopy  reports  or  personal  knowledge,  the 
concern  that  erroneous  conclusions  may  be  drawn  from  exposure  to  the 
data  base  is  a valid  one.  In  this  case,  consideration  should  be  given 
to  automating  the  remaining  values  necessary  to  make  the  data  base 
complete. 

The  "desirability"  of  the  NAVLIS  project  became  highly  suspect  at 
the  time  of,  and  was  a major  reason  for,  project  termination.  The  project 
was  the  object  of  some  criticism,  quite  a bit  of  it  from  competitive 
efforts.  The  NAVLIS  system  objectives  and  capabilities  were  in  line 
with  the  needs  of  the  Navy  and  its  logistics  managers,  even  those  managers 
sponsoring  competitive  systems,  but  the  NAVLIS  method  did  not  provide 
the  tailored  benefits  found  in  the  system  designs  of  several  of  its  critics. 

The  primary  objective  of  the  project  was  to  provide  logistics  managers 
with  access  to  data  maintained  in  data  bases  not  currently  accessible  to 
them.  These  data  bases  could  be  local  or  remote,  would  be  on-line,  and 
could  be  accessed  by  terminal  to  respond  to  ad  hoc  queries  or  to  call  for 
pre-programmed  report  generation.  The  need  for  this  capability  is  empha- 
sized by  the  several  systems  currently  proposing  to  provide  that  capabil- 
ity to  a considerably  more  restricted  user  community  and  for  a smaller 
number  of  data  bases.  Often  these  efforts  are  directed  toward  a specific 


logistics  problem  or  problem  set  as  opposed  to  a generalized  capability. 

As  a typical  example,  at  the  time  of  NAVLIS  project  termination, 
the  Naval  Air  Systems  Command  (AIR401)  was  seeking  approval  for  a system  * 
that  would  provide  managers  with  access  to  data  maintained  in  three 
existing  and  geographical ly  separate  data  bases.  At  this  point,  the 
problems  addressed  and  objectives  of  this  effort  and  NAVLIS  are  the 
same.  However,  the  non-NAVLIS  approach  pursued  in  this  project  requires 
a substantial  upgrade  in  facilities,  including  new  and  larger  computers. 

It  also  requires  "centralization"  of  the  data  base  under  a new  data 
management  system,  which  in  turn  mandates  data  base  restructuring  and 
modification  of  existing  application  programs  using  those  data  bases. 

In  anticipation  of  this  new  computing  power,  additional  applications 
and  enhancement  to  current  applications  were  also  a part  of  the  system 
proposal.  This  approach,  requiring  significant  new  hardware  procurement 
and  major  system  development  effort,  is  typical  of  many  of  today's 
logistics  information  system  developments. 

By  contrast,  under  the  NAVLIS  approach  to  the  same  problem,  the 
data  bases  to  be  accessed  remain  at  their  current  locations,  although 
they  are  placed  on-line  and  inverted  on  selected  data  elements.  This 
normally  requires  that  additional  on-line  storage  be  provided.  A tele- 
communications capability  is  provided  to  these  sites  to  be  accessed, 
if  required.  The  NAVLIS  software  modules  are  installed  on  the  current 
computers  at  each  site.  In  the  Pilot  Model  network,  additional  memory 
was  provided  at  DPSCPAC  to  support  the  system  software.  Terminals  are 
also  required  for  the  managers  who  query  the  system.  Although  some 
additional  capability  and  capacity  is  normally  a requirement  for  NAVLIS 
implementation,  it  is  limited  to  that  necessary  to  accomplish  the  primary 
objective,  i.e.,  providing  managers  with  on-line  access  to  data  bases 
currently  inaccessible  to  them.  The  capabilities  of  data  management 


* This  system  is  described  in  the  Automated  Data  System  (ADS)  Development 
Plan  for  the  Naval  Aviation  Logistics  Data  Analysis  (NALDA)  System  of 
June  9,  1975  published  bv  the  Naval  Air  Systems  Command  (AIR  401). 
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system  access  are  provided  without  relocation  or  restructuring  of  the 
data  base.  As  a result,  the  organization  and  procedures  currently 
established  for  maintaining  that  data  base  are  not  disrupted,  and  exist- 
ing application  programs  that  utilize  that  data  base  need  not  be  modified 
or  transferred  to  another  computer  (with  the  normally  attendant  conversion 
problems) . 

The  NAVLIS  approach  does  not  require  major  facility  upgrades.  The 
system  concept  is  aligned  toward  using  existing  resources  to  the 
greatest  extent  possible  and  toward  the  least  possible  impact  on  the 
operating  environments  involved.  As  such,  the  project  often  came  in 
conflict  with  other  efforts  whose  objective  of  providing  better  data 
access  to  logistics  managers  was  closely  linked  with  major  hardware 
procurements. 

The  need  for  a NAVLIS-type  system  is  perhaps  more  valid  now  than 
in  1968  at  the  inception  of  the  project.  Primary  concern  at  that  time 
centered  around: 


(a)  the  unavailability  of  current  and  reliable  data 
to  assist  in  managerial  decision-making 

(b)  the  maintenance  of  duplicate  data  at  multiple 
locations  as  a result  of  an  inability  to  share 
data 

(c)  the  increased  reporting  burden  imposed  on  the 
fleet  to  supply  input  to  these  redundant  data 
bases 

(d)  the  proliferation  of  problem-oriented  data  pro- 
cessing systems  directed  toward  a restricted 
group  of  users  as  opposed  to  the  development 

of  a lesser  number  of  generalized  systems  serving 
larger  segments  of  the  management  community. 


Each  of  the  needs  above  is  undoubtedly  more  of  a problem  today  than  it  was 
a decade  ago. 


i 
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The  continuing  proliferation  of  oroblem  specific  systems  that 
attempt  to  consolidate  existing  hut  seoarate  data  bases  by  combining 
them  into  larger  data  bases  through  "centralization"  and  "integration" 
is  evidence  that  managers  still  need  data  that  is  being  automated,  but 
is  not  readily  accessible.  Some  progress  toward  elimination  of  dunli cation 
in  several  data  bases  is  accomplished  through  consolidation,  but  on  a 
very  limited  scale.  The  amount  of  data  that  is  maintained  to  support 
logistic  management  decisions  is  awesome.  Individual  svstems  for  limited 
areas  of  logistics  access  large  quantities  of  data,  and  the  oractical 
limits  of  consolidation  are  ranidlv  reached  when  dealing  with  data 
collections  of  this  size.  The  potential  data  oool  available  through 
distributed  data  base  access  far  exceeds  that  which  can  be  accommodated 
through  centralization,  and  avoids  the  problems  associated  with  data 
restructuring  that  normally  accompany  centralizing  and  integratino. 

The  continued  multiplication  of  application  specific  systems  can 
be  attributed  to  a reluctance  to  acceot  "generalized"  systems.  Although 
generalization  as  a design  concept  is  much  lauded,  in  practice  it  is 
often  received  with  skepticism  largely  because  of  the  tendency  to  com- 
pare the  effectiveness  and  efficiency  of  generalized  systems  with 
alternative  designs  customized  for  specific  aoolications.  Such  com- 
parisons are  invariably  done  on  a one-to-one  basis.  The  result  is 
that  "generalized"  System  A,  for  one  million  dollars,  is  determined 
to  be  somewhat  less  efficient  than  "customized"  System  X,  also  for  one 
million  dollars.  The  same  conclusion  is  reached  in  other  evaluations 
when  System  A is  compared  with  customized  Systems  Y and  Z,  also  for  one 
million  each.  The  independence  of  the  evaluations  could  well  produce 
three  specialized  svstems  at  a cost  of  three  million  dollars.  In  fact, 
the  generalized  system  may  well  have  satisfied  most  of  the  require- 
ments for  each  of  the  customized  systems  at  a considerable  savings. 

In  this  example,  a half  million  dollars  of  specialized  capability  for 
each  System  X,  Y,  and  Z could  be  added  to  the  generalized  system  to 
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accommodate  their  specific  requirements  and  a cost  savings  would 
still  be  realized. 

Although  the  example  given  is  hypothetical,  the  point  is  that 
evaluation  of  system  design  efficiency  is  performed  in  a manner 
disadvantageous  to  generalized  systems.  As  NAVLIS  was  very  much  a 
generalized  system,  aimed  at  satisfying  a broad  spectrum  of  users, 
it  was  quite  vulnerable  to  this  type  comparison.  Explaining  to  a 
group  of  aircraft  engine  maintenance  managers  (who  desire  an 
information  system  for  their  specific  requirement)  that  they 
should  support  the  NAVLIS  effort  because,  although  it  will 
support  only  80%  of  their  requirements,  it  can  also  be  used  by 
ship's  maintenance  personnel,  is  likely  to  get  a chilly  reception. 

These  factors  made  it  difficult  to  generate  user  backing  for 
the  NAVLIS  project.  Original  project  sponsorship  was  at  a level 
at  which  Navy-wide  interests  predominated  and  the  generality  of 
the  system  concept  had  appeal.  However,  prior  to  project  termination, 
logistics  managers,  whose  interests  are  necessarily  more  parochial, 
were  called  on  for  support  and,  as  a result  of  the  response  received, 
the  project  was  cancelled. 


i 

t 

I 


I 

i 


1 


) 

i 


k i 


3.  TECHNICAL  PRODUCTS  AND  ACCOMPLISHMENTS 

No  technological  or  software  "breakthroughs"  were  required  to 
accomplish  the  NAVLIS  objectives.  The  system  objectives  reoresented 
an  expansion  and  integration  of  capabilities  already  available  in 
special  ourpose  orograms  or  data  management  systems  which  were 
sufficient  to  meet  those  goals.  Data  element  retrieval  in  response 
to  an  ad  hoc  query,  for  examole,  is  an  existing  capability  of  many 
software  systems.  However,  performing  that  same  function  on 
multiple  data  bases  located  at  remote  sites,  simultaneously,  is  a 
significant  expansion  of  that  data  retrieval  capability.  A list  of 
these  expansions  or  innovations  peculiar  to  NAVLIS  would  include  the 
distributed  data  directory  concept,  the  data  base  interface,  synonym 
resolution,  and  secondary  hit  resolution  capability.  Although  these 
techniques  are  not  new  in  themselves,  their  integration  represents  a 
new  application  of  proven  software  approaches  to  solve  the  NAVLIS 
problem. 

3.1  DISTRIBUTED  DATA  DIRECTORY 

An  original  concern  of  the  project  design  centered  around  the 
method  to  be  used  in  responding  to  a user's  query.  It  was  clear  that, 
in  order  to  achieve  acceptable  response  times,  some  form  of  random 
access  index  or  inverted  list,  based  on  the  values  of  selected  data 
elements  in  the  file  to  be  accessed,  would  be  reouired.  The  most 
efficient  use  of  such  lists  would  involve  co-locating  the  inverted 
files  with  their  associated  data  bases.  This  distribution  of  the 
inverted  query  lists  throughout  the  network  would  insure  that  only 
one  copy  of  each  inverted  file  would  be  maintained.  However,  to  avoid 
accessing  all  data  bases  for  each  query,  it  became  very  important 
that  the  network  be  able  to  identify  as  early  as  possible  within  the 
NAVLIS  query  processing  cycle  the  specific  data  files  which  contained 
the  data  elements  necessary  to  satisfy  the  conditions  expressed  by  a 
user's  query.  To  accomplish  that  objective,  the  Data  Directory 
Concept,  the  definition  of  each  data  base's  content  (data  elements, 
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etc.)>  was  selected.  The  Data  Directory,  defining  the  contents  of  all 
data  bases  within  the  network,  would  be  located  at  each  site  within  the 
network  and  would  be  the  primary  factor  in  the  implementation  of  an 
efficient,  distributed  query  capability.  This  directory  makes  possible 
a partial  query  determination  of  the  applicable  data  bases  at  the  user's 
site.  The  final  query  resolution,  with  the  use  of  efficient  inverted 
files,  would  occur  at  the  location  of  the  data  base.  The  application  of 
these  two  principles,  particularly  the  Data  Directory,  would  minimize 
data  transmissions,  eliminate  "no  data"  responses  from  remote  sites, 
and  identify  at  the  earliest  opportunity  queries  to  which  the  system 
could  not  respond. 
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A File  Content  Directory  was  developed  that  identified  the  contents 
of  the  data  bases  in  the  system  by  data  element  type,  e.g.,  aircraft 
model,  engine  type,  hull  number,  federal  stock  number,  etc.,  with  the  name 
and  location  of  the  data  base.  Using  this  directory,  the  File  Selection 
Module  (FSM)  can  analyze  the  user's  query  and  determine  which  data  bases 
in  the  system  contain  the  types  of  data  elements  required  to  answer  the 
query.  For  example,  to  survey  the  casualty  reporting  on  5"  54  gun  mounts 
on  attack  aircraft  carriers  for  1975,  the  user  might  submit  the  following 
query: 

IF  SHIP-TYPE  IS  CVA 

AND  EQUIP-IDENT-CODE  IS  GB17 

AND  CASREP-DATE  BE  1/1/75,  12/31/75? 

PRINT  SHIP-NAME,  CAUSE-OF-INCIDENT. 

("BE"  in  the  query  above,  means  "between  or  equal  to") 

Using  the  File  Content  Directory,  the  FSM  can  determine  which  data  bases 
in  the  system  have  the  types  of  data  elements  expressed  in  the  query 
constraints  (SHIP-TYPE,  EQUIP-IDENT-CODE,  CASREP-DATE)  and  at  least 


one  of  the  data  element  types  requested  for  retrieval  (SHIP-NAME, 
CAUSE-OF-INCIDENT).  The  data  bases  that  satisfy  these  requirements 
are  "candidates"  for  answering  the  query,  and  the  query  i sent  to 
the  sites  at  which  those  data  bases  reside.  Data  bases  not  satisfying 
the  above  requirements  are  eliminated  from  any  further  consideration. 


Although  the  candidate  data  bases  have  the  types  of  data  elements 
needed  to  respond  to  the  query,  they  may  not  have  the  values  necessary 
to  respond.  A candidate  data  base  may  have  the  data  element  SHIP-TYPE, 
but  perhaps  none  of  the  values  for  SHIP-TYPE  in  that  data  base  will 
equal  "CVA",  in  which  case  that  data  base  cannot  respond  to  the  query. 
Determining  whether  the  required  values  are  present  is  a function  of 
the  Primary  Hit  Resolution  Module  using  the  inverted  files  which 
identify  the  values  in  that  data  base  for  each  data  element  on  which  the 

data  base  is  inverted.  Consequently,  some  "no-data"  or  "no-hit" 
responses  would  still  occur,  but  considerably  fewer  would  occur  as  a 

result  of  the  File  Content  Directory's  oreselection  of  data  bases 
than  would  be  the  case  if  the  query  were  transmitted  to  all  sites 
regardless  of  the  data  content  of  their  files. 

The  directory  function  would  be  distributed  throuqhout  the 
network.  The  Executive  sites  (those  sites  capable  of  acceoting  and 
analyzing  a Query)  would  each  have  a copy  of  the  smaller,  less 
volatile,  and  more  maintainable  component,  the  File  Content  Directory, 
and  all  system  sites  would  have  the  inverted  files  that  pertain  to 
their  data  bases. 


3.2  DATA  BASE  INTERFACE 
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One  of  the  most  challenging  requirements  of  the  NAVLIS  system  was 
that  it  retrieve  data  from  existing  data  bases  without  restructuring 
or  reformatting  those  data  bases,  The  objective  was  to  gain  access 
to  the  file  without  causing  extensive,  or  even  moderate,  changes  in 
the  application  programs  currently  using  those  files.  This  meant  that 
NAVLIS  had  to  be  equally  capable  of  interfacing  with  data  files  designed 
for  second  generation  batch  processing  and  with  those  structured  under 
sophisticated  data  management  systems.  In  the  early  stages  of  the 
project,  for  both  expediency  and  experience,  a unique  module  was  developed 
to  achieve  the  interface  with  each  data  base.  By  project  termination, 
however,  a generalized  data  base  interface  had  been  defined  and  was 
in  development  (see  Section  7.1.1  for  discussion  of  the  Generalized 
"ADS  Interface").  The  generalized  program  would  have  enabled  a single 
module  to  access  several  files  at  a single  site.  It  would  also  have 
minimized  the  effort  required  to  include  a new  data  base  in  the  NAVLIS 
network. 


3.3  SYNONYM  RESOLUTION 

The  requirement  for  a synonym  resolution  capability  sprang  directly 
from  the  requirement  to  access  multiple  data  bases  without  modification. 
There  is  little,  if  any,  standardization  across  data  bases,  even  when 
the  area  of  interest,  e.g.,  aircraft  engine  maintenance,  is  the  same. 

In  some  cases  the  only  apparent  similarity  is  in  the  data  element  names, 
e.g.,  aircraft  type,  ship  name.  In  one  data  base,  "aircraft  type"  may 
include  the  series  and  model  number,  whereas  in  a second  data  base  all 
three  elements  may  be  recorded  as  separate  fields.  A data  element  such 
as  "ship  name"  presents  additional  problems  in  that  there  may  be  several 
permutations  within  the  same  data  base  for  the  name  of  a specific  ship. 
Additionally,  an  item  may  be  referred  to  by  a code  number  in  one  file 

s 

and  by  name  in  another.  These  differences  in  identification  required 
resolution  so  that  a user  could  retrieve  data  relevant  to  his  query 
without  entering  multiple  identification  types  for  the  item  of  interest. 
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Additional  discussion  of  the  Synonym  Resolution  Module  may  be  found  in 
Section  8.1.2. 

The  significance  of  the  synonym  resolution  capability  is  not  only 
that  it  provided  a method  of  overcoming  a lack  of  data  element  standard- 
ization between  and  within  data  bases,  but  that  the  terminal  user  has 
considerably  more  flexibility  in  phrasing  and  entering  his  query  than 
before.  The  user  can  phrase  the  query  in  the  nomenclature  most  familiar 
to  him  and  be  assured  that  it  will  be  translated  as  appropriate  at 
various  other  locations  to  retrieve  the  data  requested.  In  both  the 
Pilot  Model  and  the  San  Diego  demonstration,  commonly  accepted  abbrevi- 
ations and  acronyms  were  included  to  facilitate  querying,  rather  than 
trying  to  rectify  conflicts  across  data  bases.  Acronyms  such  as  "CINCPACFLT 
"CPF",  "COMNAVAIRPAC",  "CNAP",  AND  "DPSCPAC"  are  many  times  easier  to 
use  in  query  construction  than  the  expanded  titles  they  represent. 

Synonym  resolution  created  some  problems  that  were  still  to  be 
resolved  at  project  termination  (see  Section  8.1.2).  The  difficulties 
arose  primarily  when  synonym  resolution  was  combined  with  certain 
options  available  in  the  query  language.  Those  problems,  however, 
are  surmountable  and  their  difficulty  is  far  outweighed  by  the  benefits 
derived  from  synonym  resolution. 

3.4  SECONDARY  HIT  RESOLUTION 

Random  access  was  clearly  a requirement  for  the  NAVLIS  system  to 
provide  a reasonable  response  time  for  on-line  users.  Since  the 
structures  of  the  data  bases  to  be  accessed  were  not  to  be  modified, 
the  addition  of  pointers  or  links,  or  the  reorganization  of  the  data 
base  records  into  some  logical  relationship,  were  eliminated  as  methods 
of  providing  random  access.  The  creation  of  inverted  files  as  indices 
to  the  contents  of  the  data  bases,  and  the  use  of  the  Indexed  Sequential 
Access  Method,  enabled  random  access  without  adding  to  or  restructuring 
the  data  bases.  The  Primary  Hit  Resolution  Module  (PHRM)  uses  the 
inverted  files  to  perform  hit  resolution.  If,  for  example,  the  following 
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query  is  input: 
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IF  ITEM-NAME  IS  ABC 

AND  STATUS-CODE  IS  A1 

PRINT  ITEM-NAME,  DATE-REPAIRED. 


t 
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PHRM  accesses  the  inverted  files  and  determines  the  record  keys  for 
those  records  that  have  the  value  "ABC"  in  the  ITEM-NAME  field.  The 
record  keys  for  words  containing  "Al"  in  the  STATUS-CODE  field  are 
also  determined.  PHRM  examines  the  two  groups  of  keys  and  any  record 
key  found  in  both  groups  satisfies  the  conditions  of  the  query.  When 
all  the  data  elements  expressed  in  the  query  conditions  or  constraints 
(ITEM-NAME  and  STATUS-CODE  in  the  example  given)  have  been  inverted, 

PHRM  can  identify  the  specific  records  to  be  accessed  for  data  retrieval. 
Inversion,  however,  is  not  performed  on  all  data  elements  in  a data  base. 
Inverting  on  too  many  data  elements  and  on  data  elements  with  many  unique 
values  in  a data  base,  such  as  quantities,  can  easily  produce  an  inverted 
file  that  exceeds  the  size  of  the  data  base.  To  keep  the  size  of  the 
inverted  files  reasonable,  only  selected  data  elements  are  inverted. 

Those  data  elements  selected  should  be  those  most  likely  to  appear  as 
constraints  in  the  majority  of  queries  against  that  data  base. 

The  user  of  the  system,  however,  should  be  able  to  retrieve  data 
regardless  of  whether  the  data  base  has  been  inverted  on  all  the  con- 
straints in  the  query.  The  fact  that  a query  is  entered  with  constraints 
that  were  not  selected  for  inversion  should  not  invalidate  that  query. 

The  system  objective  was  to  be  able  to  retrieve  on  non-inverted  data 
elements.  This  capability  alleviates  both  the  requirement  for  total 
data  base  inversion  and  for  the  user  to  be  aware  of  which  data  elements 
were  inverted  in  any  specific  data  base.  In  the  example  given,  either 
ITEM-NAME  or  STATUS-CODE  or  both  could  be  non-inverted  data  elements. 

If  STATUS-CODE  was  not  inverted,  PHRM  would  access  the  inverted  files 
to  determine  the  record  keys  with  the  value  "ABC"  in  the  ITEM-NAME  FIELD, 
These  record  keys  would  be  passed  to  the  ADS  Interface  Module  along  with 
an  indicator  from  PHRM  that  only  partial  hit  resolution  had  been  performed. 
The  ADS  Interface  Module  would  then  access  each  record  identified  by  PHRM 
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and  test  the  contents  of  the  STATUS-CODE  field  against  the  constraint 
value  "A1".  Those  records  that  satisfied  that  test  would  satisfy  the 
query  constraints  and  the  ADS  Interface  Module  would  retrieve  the 
requested  data  elements.  Although  the  example  used  here  is  extremely 
simple,  the  ADS  Interface  Module  under  development  at  project  termination 
included  the  capability  to  resolve  all  the  search  criteria  expressible 
in  the  query  language. 

The  ADS  Interface  Module  also  included  the  capability  to  retrieve 
data  when  none  of  the  query  constraints  were  inverted.  This  involved 
reading  the  entire  data  base  sequentially,  since  without  inversion 
PHRM  is  unable  to  do  any  preliminary  hit  resolution.  The  response  time 
for  this  type  of  search  is  prohibitive  except  when  access  to  the  data 
is  a requirement  and  no  other  query  formulation  will  produce  the  same 
results. 

The  secondary  hit  resolution  capability  v;as  incorporated  in  the 
NAVLIS  system  so  the  user  would  not  be  restricted  in  his  query  input 
to  those  data  elements  that  were  inverted,  and  so  that  the  number  of 
data  elements  selected  for  inversion  could  be  reduced  while  still 
providing  acceptable  response  time.  Response  time  does  increase  when 
secondary  hit  resolution  is  required,  but  the  cost  in  time  is  usually 
worth  the  increased  accessibility  of  data.  An  exception  would  be  when 
the  entire  data  base  must  be  read  to  answer  the  query.  The  user  would 
then  have  to  determine  his  priorities  among  time,  money  and  data. 
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4,  REQUIREMENTS  ANALYSIS/FLEET  APPLICATIONS 

At  the  time  of  NAVLIS  project  termination,  CINCLANTFLT,  Norfolk, 
Va.  and  the  Atlantic  Fleet  Data  Processing  Service  Center  (DPSCLANT) 
were  involved  with  on-going  NAVLIS  efforts.  Both  efforts  are  described 
in  the  following  paragraphs. 


4.1  CINCLANTFLT  EFFORT 

The  CINCLANTFLT  effort  dealt  with  ship  overhaul  funding  and  schedul- 
ing in  the  Atlantic  Fleet  in  support  of  the  Maintenance  and  Material 
Readiness  Division  and  is  described  in  greater  detail  in  Appendix  B 
of  this  report.  This  application  was  designed  to  permit  the  ready 
: retrieval  of  data  to  facilitate  the  production  of  the  Monthly  Report 

) of  Overhaul  Expenditures.  This  report,  which  receives  wide  distribution 

at  the  NAVMAT,  CNO,  SYSCOM,  and  Fleet  staffs,  tracks  the  performance  of 
I the  fleet  overhaul  program.  The  fleet  overhaul  program  entails,  over  a 

seven-year  period,  the  scheduling  and  budget  programming  for  over  300 
ships.  The  annual  maintenance  program  is  in  excess  of  $300  million. 

As  an  extension  of  this  application,  the  following  efforts  were  being 
' initiated  at  project  termination; 

t 

1 (a)  Investigation  of  the  Maintenance  Planning  and  Performance 

Accounting  System 

J 

t The  purpose  of  the  Maintenance  Planning  and  Performance 

I 

j Accounting  System  is  to  assist  the  planning  for  allocation 

} of  resources  for  shipyard,  intermediate  level,  and  shipboard 

j maintenance,  and  to  account  for  their  accomplishment. 

* In  the  current  application,  maintenance  resources  are  funds 

and  personnel.  Additionally,  the  system  facilitates  the 
■ preparation  and  submission  of  the  several  inputs  required 

by  the  annual  budget  cycle,  provides  the  basis  for  evaluating 
the  effects  of  alternative  funding  schedules  on  fleet  main- 
tenance, and  serves  as  a basis  for  evaluating  the  effective- 
ness of  the  fleet  maintenance  program.  ; 
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The  Maintenance  Planning  and  Performance  System  is  depicted 
in  Figure  3 for  the  Depot  or  Shipyard  level,  in  Figure  9 for 
the  Intermediate  Maintenance  Activity  level,  and  in  Figure  5 
for  the  Organizational  or  Shipboard  level.  The  following 
section  discusses  the  features  of  the  system  for  accounting 
for  each  level  of  maintenance  activity.  Data  sources  and 
requirements  are  keyed,  by  number,  to  the  appropriately 
numbered  blocks  on  each  figure  and  to  the  following  paragraphs. 

( ^ ) Investigation  of  the  C I NCLWiT  Pj 3nnjj*i 

Performance  Accounting  System  which  A'lcpiIlPAl?®-!  the 

1)  Shipyard  (Depot)  Level  Maintenance  (Figure  3) 

The  point  of  entry  to  the  Maintenance  Planning  and  Performance 
Accounting  System  has  been  the  Monthly  Report  of  Overhaul 
Expenditures.  This  report  shows  how  well  the  annual  overhaul 
program  is  being  executed.  It  lists,  by  ship,  projected 
shipyard  overhaul  start  and  departure  dates,  projected 
fund  availabil ity,  and  the  actual  start  and  departure  dates 
as  well  as  the  actual  expenditures  to  date.  Experience  has 
demonstrated  that  approximately  two  man-weeks  are  required 
at  each  TYCOM  and  an  additional  two  man-weeks  are  expended 
at  the  CINCLANTFLT  level  for  the  manual  production  of  this 
report. 

The  platen  dimensions  of  the  presently  available  computer 
terminal  preclude  the  on-line  production  of  the  final  report. 
However,  the  data  for  report  preparation  can  be  assembled  in 
less  than  thirty  minutes. 

2)  Overhaul  and  Restricted  Availability  and  Technical 
Availability  Program  (Schedule  and  Funding) 

The  production  of  the  Monthly  Report  of  Overhaul  Expenditures 
requires  data  pertaining  to  both  the  planned  maintenance  program 
and  the  program  accomplishment.  The  Overhaul  and  RAV/TAV  Program 
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Figure  3 - Shipyard  (Depot)  Level  Maintenance 


comprises  three  principal  data  files,  the  Five-Year  Defense 
Program  (FYDP),  the  series  of  budget  submissions  prepared 
by  the  Maintenance  and  Material  Readiness  Division,  and 
the  Schedule  of  Ship  Overhauls.  Data  from  these  files  can 
be  used  analytically  to: 

* Prepare  further  budget  submissions 

® Examine  the  effects  of 

- Slippage  of  scheduled  overhauls 

- Cancellation  of  scheduled  overhauls 

- Reduction  in  ship  maintenance  program  funding 

- Extension  or  compression  of  intervals  between 
overhauls 

- Acquisition  or  loss  of  individual  ships 

- Reduction,  or  increase,  of  time  (and  work) 
accomplished  during  overhauls. 

3)  Five-Year  Defense  Program  (FYDP)  (1) 

This  file,  currently  input  and  updated  manually,  will  interface 
in  later  system  refinements  with  the  Fleet  Financial  Management 
Information  System.  The  FYDP  is  used  as  the  base  line  mainte- 
nance funding  requirement.  It  contains  data  for  the  previous 
fiscal  year  (FY),  the  current  FY,  the  budget  year  (BY),  and 
five  forward  years,  or  out  years.  This  departure  from  the 
standard  FYDP  format  is  necessary  because  a ship  can  be  in  a 
shipyard  for  overhaul  for  a period  encompassing  three  FY's. 

4)  Budget  Submissions  (2) 

During  the  budget  cycle,  the  Maintenance  and  Material  Readiness 
Division  is  required  to  prepare  and  submit  several  modifications 
to  the  maintenance  program  to  reflect  changes  in  guidance. 
Although  the  final  preparation  and  verification  of  each  sub- 
mission must  be  performed  manually,  the  storage,  retrieval. 
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and  comparative  analysis  of  successive  submissions  is  facilitated 
by  the  system.  Data  element  descriptions  contained  in  this  file 
are  similar  to  those  in  the  FYDP  file. 

5)  Overhaul  Schedule  (3) 

The  overhaul  schedule  reflects,  by  ship,  the  proposed  start  and 
departure  dates  for  shipyard  maintenance.  Although  this  schedule 
is  currently  produced  manually,  it  does  interface  with  similar 
data  residing  in  the  Ship  Alteration  Management  Information 
System  (SAMIS),  and  to  a lesser  extent  in  the  Ship  Equipment 
Configuration  System  (SECAS).  The  implementation  of  a NAVLIS 
type  network  would  permit  automated  cross  update  and  retrieval 
of  overhaul  schedules.  Although  these  three  separate  files 
are  described  individually,  they  are  interrelated,  in  that 
changes  to  the  funding  program  can,  and  do,  create  changes  in 
the  shipyard  availability.  Conversely,  changes  in  shipyard 
availability  can,  and  do,  create  changes  in  the  funding  program. 

6)  Maintenance  Accomplishment 

At  the  CINCLANTFLT  level,  maintenance  accomplishment  is  measured 
in  terms  of  material  costs  and  man  hours  (or  days)  expended,  and 
of  course,  in  terms  of  adherence  to  the  basic  overhaul  schedule. 

7)  Man  Hours  (4)  and  Material  Costs  (5) 

Man  hours  (or  man  days)  and  material  expenditures  are  currently 
reported  in  the  Departure  Report,  prepared  and  submitted  by  the 
shipyard  upon  completion  of  an  overhaul.  Although  the  changes, 
in  dollars,  for  labor  are  reflected  in  the  report,  analyses  of 
program  effectiveness  and  comparison  of  shipyard  productivity 
are  based  on  man  hours  or  man  days  expended  to  accomplish 
scheduled  overhauls. 


Later  phases  of  the  application  should  interface  with  the 
Shipyard  Management  Information  Systems,  whenever  they  are 
impl emented, 

8)  Schedule  Adherence  (6) 

Messages  received  by  the  Maintenance  and  Material  Readiness 
Division  announce  the  arrival,  progress,  completion,  and 
departure  of  ships  at  maintenance  facilities.  These  messages 
are  manually  entered  into  a file  and  reflect  the  status, 
or  progress,  of  the  overhaul.  Comparison  of  the  data  in 
this  file  with  that  contained  in  the  overhaul  schedule  shows 
the  adherence  to,  or  departures  from,  the  approved  schedule, 
and  serves  as  a flag  for  appropriate  staff  action. 

9)  Overhaul  Program  Effectiveness  Analyses 

Although  there  is  currently  no  ad  hoc  NAVLIS  capability  for 
extracting  data  from  a file,  bringing  the  data  into  a work 
space,  performing  mathematical  operations,  and  returning 
the  results  to  the  same  or  a new  file,  this  capability  is 
recognized  as  a requirement  for  any  NAVLIS  type  system. 

Most  commercial  time  sharing  systems  provide  for  such 
operations.  Hence,  the  current  system  at  CINCLANTFLT 
possesses  no  automated  analytic  capability.  Data  for  anal- 
yses are  extracted  from  the  files  and  manually  manipulated. 


Program  effectiveness  analyses  comprise: 

• Analysis  of  labor  and  material  expenditures  for 
like  work  at  different  shipyards  for  similar  ships. 

• Analysis  of  labor  and  material  expenditures  at  the 
same  shipyard  for  both  similar  and  different  ships. 

• Analysis  of  programmed  expenditures,  with  actual  charges. 

• Analysis  of  expenditures  for  overhauls  versus  age  of  ships. 

• Analysis  of  historical  overhaul  expenditures  for  like 
ships  of  the  same  age  at  the  same  and  different  shipyards. 
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(c)  An  Investigation  of  the  Intermediate  Maintenance  Activity  (IMA) 
Planning  and  Performance  Accounting  - Figure  4 

Actual  implementation  of  the  IMA  Module  and  the  Organizational 
Maintenance  Module  of  the  Maintenance  Planning  and  Performance 
System  was  not  accomplished.  Description  of  desired  data,  file 
content,  and  analytic  operations  were  derived  from  discussions 
with  the  staff  of  the  CINCLANTFLT  Maintenance  and  Material 
Readiness  Division. 

The  basic  structure  and  concept  of  operation  for  the  IMA  and 
Organizational  Modules  is  similar  to  that  for  the  Shipyard 
(or  Depot)  Maintenance  Modules.  The  schedule  of  work  and 
associated  plans  for  resource  allocation  are  compared  and 
contrasted  with  reports  of  actual  mairitenance  performance 
and  resource  expenditures.  In  some  cases,  the  present  avail- 
ability of  data  is  limited.  For  example,  the  only  data 
available  on  shipboard  material  consumption  was  in  the  supply 
system  report  of  material  expenditures.  However,  the  systems 
described  herein  have  been  designed  to  start  operations 
immediately  using  the  presently  available  data. 

IMA  operations  are  programmed,  planned,  and  supervised  by  the 
Type  Commands  (TYCOMs)  under  the  guidance  of  the  Maintenance 
and  material  Readiness  Division  of  CINCLANTFLT. 

1)  Intermediate  Maintenance  Activity  Scheduling 

The  Maintenance  and  Material  Readiness  Division  announces  the 
Fleet  guidance  for  the  number  of  days  of  tender  availability, 
per  calendar  quarter,  to  be  scheduled  by  the  TYCOM.  Quarterly 
scheduling  conferences  provide  the  vehicle  for  firming  up  the 
schedule  and  for  considering  operational  requirements  which 
might  result  in  adjustments  in  the  schedule.  From  this  schedule 
are  derived  the  requirements  for  funds  for  material  and  require- 
ments for  needed  technical  personnel. 
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Figure  4 - Intermediate  Maintenance  Activity  (IMA)  Planning 
and  Performance  Accounting 


2)  Estimated  Material  Funding  Requirements  (7) 

Requirements  for  material  funding  for  IMAs  are  prepared  and 
submitted  both  annually  and  quarterly  by  the  TYCOMS.  Annual 
requirements  are  generally  for  the  entire  TYCOM;  quarterly 
requirements  are  by  individual  IMA.  These  requirements  and 
LANTFLT  quarterly  allocations  are  prepared  manually  after 
the  quarterly  IMA  schedule  has  been  prepared.  It  was  antici- 
pated that  later  phases  of  the  system  implementation  would 
interface  directly  with  the  IMA  material  program  files  to 
be  incorporated  into  the  CINCLANTFLT  Financial  Management 
Information  System. 

3)  Quarterly  IMA  Schedule  (8) 

This  file  contains  the  schedule  of  IMA  availabilities  resulting 
from  the  IMA  scheduling  conference.  It  contains,  by  IMA,  the 
planned  arrival  and  departure  dates  of  each  ship  serviced  by 
the  IMA.  The  schedule  is  sufficiently  flexible  to  permit 
changes  resulting  from  operational  requirements,  but  it  does 
permit  the  planning  to  ensure  the  best  IMA  utilization. 

Further,  it  ensures  that  ships  with  peculiar  problems  are 
supported  by  It'iAs  with  special  capabilities. 

4)  Personnel  Requirements  (9) 

The  oata  in  this  file  result  from  reports  from  the  TYCOM, 

IMAs,  and  the  ships,  which  indicate  that  special  skills  and 
qualifications  of  personnel  are  either  in  short  supply  or 
are  excess  to  requirements.  This  information  is  used  to 
ensure  that  appropriate  action  is  taken  to  acquire  or 
transfer  personnel  to  facilities  possessing  the  requirements. 

5)  IMA  Program  Accomplishment 

The  data  for  IMA  program  accomplishment  are  currently  reported 
under  the  3-M  system  and  is  processed  at  DPSCLANT  by  the 
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Intermediate  Maintenance  Management  System  (IMMS).  These 
data  are  reported  monthly  by  each  IMA. 

6)  Material  Funds  Expended  (10) 

This  IMMS-derIved  data  reports,  by  IMA  work  center  and  by 
ship  tended,  the  dollar  value  of  the  material  expended 
during  the  reporting,  period.  Data  elements  include  tender 
identification,  work  center,  ship  tended,  and  dollar  value 
of  material  util ized. 

7)  Man  Hours  Expended  (11) 

The  same  reports  which  provide  data  pertaining  co  Material 
Fund  expenditures  also  provide  the  report  of  man-hour 
utilization.  3-M  data  submitted  by  the  IMA  is  processed 
at  DPSCLANT  in  the  IMMS  system  to  derive,  by  work  center 
and  ship  tended,  the  number  of  man  hours  expended.  In  addition 
the  file  will  contain  the  number  of  personnel  available  at 
each  work  center.  Thus,  the  data  in  this  file  can  provide 
insight  to  the  degree  of  personnel  utilization,  by  work 
center,  during  the  period. 

8)  Schedule  Adherence  (12) 

Each  IMA  currently  reports  the  arrival  and  departure  dates 
of  every  ship  tended.  Additionally,  it  reports  the  work 
accomplished  and  the  status  of  the  Current  Ship  Maintenance 
Plan  (CSMP)  for  each  ship  tended.  These  reports  are  processed 
monthly  at  the  DPSC  using  IMMS.  These  data  are  currently 
available  for  application  to  NAVLIS.  Comparison  of  the  data 
contained  in  this  file  with  the  data  contained  in  the  Quarterly 
Schedule  file  will  show  the  degree  of  adherence  to  the  schedule 

9)  Intermediate  Maintenance  Program  Effectiveness 

The  six  data  files  of  the  IMA  Planning  and  Performance  Account- 
ing module  contain  the  basic  data  to  permit  analysis  of  the 
IMA  program.  As  experience  is  gained  in  the  use  of  the  system. 


more  incisive  results  will  be  attained  and  more  sharply  defined 
data  will  be  added  to  the  files.  The  initial  analyses  will 
doubtless  identify  areas  in  which  increased  insight  is  desirable. 

Analytic  results  expected  to  be  attained  initially  from  the 
data  are: 

” Adherence  to,  and  departures  from,  the  scheduled 
aval labi 1 i ties. 

" Amount  of  unscheduled  IMA  availability  and  historical 
trends. 

” Effectiveness  of  man  power  and  material  utilization  of 
each  IMA,  and  the  relative  effectiveness  of  each  IMA 
when  compared  with  all  others. 

” Status  of  the  CSMP  and  comparison  with  previous  data  and 
indicated  trends. 

° Identification  of  problem  areas  such  as  manpower  or 
material  shortages. 

° A basis  for  work  load  leveling  among  the  IMA's. 

( d ) PT'-  PX  JtA®.  PtPAPJPP tjPPP.L  Maintenance  _P_1  ann i ng  a n^ 

^.PT/PJT'APPP.  i^ccpun tj  ng  Modul  e Fjgure_5 

The  currently  available  data  for  inclusion  in  this  module  are 
very  sparse.  It  is  planned  to  implement  the  OM  Planning  and 
Performance  Module  using  only  presently  reported  and  available 
data,  and  to  determine  whether  useful  results  can  be  obtained. 
Should  additional  data  be  required,  then  appropriate  measures 
will  be  taken  to  determine  whether  data  can  be  secured  from 
existing  reporting  systems.  Only  as  a last  resort  will 
additional  reporting  requirements  be  levied  upon  shipboard 
maintenance  personnel. 

1)  Shipboard  Maintenance  Capability 

As  for  the  shipyard  and  IMA  Modules  this  module  is  configured 
to  provide  data  on  material  funds,  personnel,  and  schedules 
for  shipboard  maintenance. 


Figure  5 - Organizational  Maintenance  and  Performance  Accounting 


2)  Material  Fund  Estimates  (13) 

Estimates  of  funds  required  for  material  to  be  used  in  the 
accomplishment  of  organizational  maintenance  are  submitted 
by  each  ship  to  the  TYCOM.  The  TYCOM  maintenance  and  supply 
staffs  make  the  necessary  adjustments  and  submit  them  to  the 
CINCLANTFLT  Maintenance  and  Material  Readiness  Division, 
which  in  turn  consolidates  TYCOM  estimated  requirements  for 
inclusion  in  the  budget  program.  This  file  will  contain  the 
values  of  the  funds  for  material  programmed  for  each  ship 
for  the  FY. 

3)  Personnel  Requirements  (14)  and  Schedule  of  Maintenance  (15) 

At  this  time  sources  for  these  data  have  not  been  identified. 
Exception  data  reported  through  the  CASREP  and  3-M  Systems  are 
potential  sources.  Summary  data  from  IMMS  can  provide  some 
insight  to  the  CSMP. 

4)  Shipboard  Maintenance  Accomplishment 

These  files  contain  historical  data  on  organizational  maintenance 
accomplishment.  Comparison  of  these  data  with  the  data  describing 
the  organizational  maintenance  capability  provides  insight  into 
the  effectiveness  of  shipboard  maintenance. 

5)  Material  Funds  Expended  (16) 

Data  in  this  file  are  derived  from  supply  system  reports  which 
periodically  report  by  ship  and  cognizant  activity  the  dollar 
value  of  material  furnished  to  each  ship. 

6)  Man  Hours  Expended  (17)  and  Work  Accomplished  (18) 

Data  for  these  files  are  not  currently  directly  available.  The  3-M 
'•  System  does  provide  for  some  data,  such  as  exceptions  reported  for 
particular  equipment  systems,  or  repairs  beyond  the  capability  of 
the  organizational  maintenance  resources. 
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It  is  believed  that,  with  monor  modifications,  insight  into 
shipboard  maintenance  accomplishment  can  be  acquired  from 
the  IMA,  Fcr  example,  changes  in  the  CSMP  back  log  could 
provide  information  on  personnel  qualifications  and  numbers. 

7)  Organizational  Maintenance  Effectiveness  Analysis 

Initial  measures  of  organizational  maintenance  effectiveness 
will  be  related  to  the  expenditures  for  material  and  changes 
en  the  CSMP.  Later  analysis  will  be  predicated  upon  man  power 
availability  and  utilization,  and  on  scheduled  workload 
adherence. 

8)  CINCLANTFLT  Maintenance  Program  Effectiveness 

Output  of  the  three  basic  modules,  (1)  Shipyard  Maintenance 
Module,  (2)  IMA  Module,  and  (3)  the  Organizational  Module, 
will  be  configured  to  be  directly  comparable.  Typical  analyses 
will  include: 

• Relative  costs  of  each  level  of  liiaintenance 

• Relative  productivity  of  each  maintenance  echelon 

• Comparative  effectiveness  of  each  maintenance  facility 

• Comparative  maintenance  system  effectiveness  for 

- Like  sliip  types 

- Various  ages  of  like  ship  types 

- Alternative  maintenance  strategies 

- A1 ternative  maintenance  intervals 

- Alternative  funding  strategies 

4.2  DPSCLANT  EFFORT 

The  Data  Processing  Service  Center,  Atlantic  Fleet  was  preparing 
to  implement  the  NAVLIS  Executive  System  on  its  Spectra  70/45  in  prepar- 
ation for  two  major  DPSCLANT  efforts: 
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1)  the  incorporation  of  the  Center  as  an  operating  node 
(site)  on  the  NAVLIS  Pilot  Network 

2)  the  establishment  of  an  initial  on-line  capability 
at  the  Center  to  suooort  the  local  TYCOMS  and  other 
interested  (and  funded)  users. 

The  NAVLIS  termination  will  undoubtedly  haye  an  adyerse  effect  on  the 
ability  of  DPSCLANT  to  meet  at  the  second  objectiye  which  would  haye 
contributed  directly  to  the  operational  effect! yeness  of  the  Fleet. 
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5.  PILOT  MODEL  STATUS  AT  PROJECT  TERMINATION 


At  the  termination  of  the  NAVLIS  project  every  major  module  in  the 
NAVLIS  system  was  undergoing  significant  enhancement.  There  were 
actually  two  separate  NAVLIS  versions.  An  "executable"  system  was 
installed  and  was  being  tested  at  the  Naval  Material  Command  Supoort 
Activity  (NMCSA)  in  Arlington,  Virginia,  and  the  Data  Processing 
Service  Center  for  the  Pacific  (DPSCPAC)  in  San  Diego,  California. 

The  second  version  was  a "development"  version  with  module  debugging 
and  modification  occurring  on  the  IBM  360/65  and  370/165  at  NMCSA 
and  on  the  UNIVAC  Spectra  70/45  at  the  Navy  Command  Systems  Suooort 
Activity  (NCSSA)  in  Washington,  D.C.  The  development  version 
evolved  partially  in  response  to  practical  problems  encountered  while 
testing  the  executable  version  at  DPSCPAC  and  NMCSA.  Enhancements 
to  the  development  version  were  in  preparation  for  expansion  of  the  pilot 
model  network  and  included  significant  new  capabilities,  such  as  secondary 
hit  resolution,  multiple  executives,  increased  hit  resolution  efficiency, 
and  access  to  a non-DMS  supported  data  base.  Most  of  the  coding  required 
for  these  new  capabilities  had  been  incorporated  into  the  modules  at 
project  termination,  but  module  testing  had  not  been  completed  and  integrated 
testing  had  not  begun.  The  status  of  both  the  executable  and  development 
versions  is  discussed  in  more  detail  below. 

5.1  "EXECUTABLE"  NAVLIS  PILOT  MODEL 

This  version  of  the  NAVLIS  Pilot  Model  system  had  been  implemented 
and  was  being  used  for  system  testing  at  DPSCPAC  in  San  Diego  and  NMCSA 
in  Arlington,  Virginia.  The  executive  software  was  resident  on  DPSCPAC's 
UNIVAC  Spectra  70/45,  and  the  remote  or  satellite  software  was  installed 
on  NMCSA's  360/65  and  370/165.  The  executive  software  provided  DPSCPAC 
with  considerably  more  capability  than  a satellite  site.  An  executive 
site  had  the  following  capabilities: 
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a.  Processing  user's  log-on 

b.  Accepting  and  processing  queries 

c.  Accepting  and  processing  report  definitions 

d.  Accepting  user  specified  file  parameters  for 
limiting  data  base  searches 

e.  Performing  "file  selection",  i.e.,  determining  which 
data  bases  in  the  network  could  respond  to  the  query 

f.  Transmitting  and  receiving  data  from  other  network  sites 

g.  Performing  synonym  resolutions 

h.  Performing  hit  resolutions 

i.  Accessing  data  bases  and  retrieving  data 

j.  Accumulating  responses  from  all  sites 

k.  Sorting  response  data  as  required 

l.  Generating  output  reports 

A satellite  site  had  the  software  capable  of  performing  only  functions 
f,  g,  h and  i above. 

For  this  initial  test  version  of  NAVLIS,  two  data  bases  were 
accessible  to  users,  the  Aircraft  Power  Plant  Management  System 
(APPMS)  at  DPSCPAC  and  the  Aircraft  Engine  Accounting  (AEA)  file  at 
NMCSA.  The  APPMS  data  base  was  supported  by  the  SHARP  data  management 
system  at  DPSCPAC  which  made  the  NAVLIS  interface  to  that  data  base 
relatively  simple  as  NAVLIS  and  SHARP  have  much  retrieval  software  in 
common.  The  AEA  data  base  at  NMCSA  was  supported  by  IBM's  IMS  data 
management  system.  This  system  required  a special  NAVLIS  interface 
to  that  data  base,  which  was  quite  complicated. 

A typical  testing  session  involved  the  input  of  test  queries  from 
DTNSRDC  to  retrieve  data  from  either  or  both  of  the  systems  data  bases. 

A portable  terminal  and  dial-up  communications  were  used  to  establish 
contact  with  the  executive  site  at  DPSCPAC.  Dial-up  telephone  lines 
were  also  used  to  establish  communication  between  the  two  computers. 
Pre-test  preparations  required  telephoning  the  operators  at  both  DPSCPAC 
and  NMCSA  to  bring  the  system  up.  DPSCPAC  then  made  the  dial-up  con- 
nection between  the  Spectra  70/45  and  the  360/65  (or  370/165).  The  user 


37 


f 


•'  then  dialed  in  to  the  DPSCPAC  Spectra  70/45  to  make  the  terminal  connec- 

tion to  the  executive  software  package.  With  communication  established, 

. the  NAVLIS  System  was  ready  to  accept  queries  or  report  definitions. 

The  queries  were  designed  to  test  as  many  of  the  system  features  as 
possible.  The  inevitable  "bugs"  discovered  were  rectified  in  the 
"development"  modules,  unless  they  significantly  impacted  the  testing 
process,  in  which  case  they  were  corrected  in  both  the  development  and 
the  executable  versions. 

Query  input  was  accepted  and  edited  by  the  Query  Translation 
Module  (QTM)  at  the  "executive"  site.  Once  the  query  had  been  received 
and  validated,  the  File  Selection  Module  (FSM)  interfaced  with  the  user 
to  determine  whether  the  user  wished  to  supply  file  descriptors  or 
i parameters  to  limit  the  data  retrieval  to  certain  types  of  data  bases, 

! FSM  then  identified  those  data  bases  in  the  NAVLIS  System  that  were 

‘ candidates  to  respond  to  the  user's  query  and  satisfy  the  file  parameters 

the  user  provided,  if  any,  FSM  generated  copies  of  the  query  to  go  to 
' each  satellite  or  remote  site  containing  a candidate  data  base.  The 

Executive  Control  Module  (ECM)  and  the  NAVLIS  Telecommunications  Subsystem 
(NTS)  effected  the  transmission  of  the  queries  to  the  appropriate  sites. 

The  Pilot  Model,  as  it  existed  at  project  termination,  had  only  one  remote 
‘ site,  at  NMCSA,  In  practice,  the  queries  normally  required  accessing  the 

AEA  file  at  NMCSA  and  the  APPMS  file  at  DPSCPAC, 

« 

After  a copy  of  the  query  was  transmitted  to  NMCSA  for  AEA  file  access, 
: vnth  a copy  retained  at  DPSCPAC  for  APPMS  file  access,  the  following  actions 

i occurred  simultaneously  at  both  sites.  The  Synonym  Resolution  Module 

I examined  the  Synonym  Resolution  File  and  the  query  to  determine  whether 

: any  search  acronym  or  value  translations  were  required  to  make  the  expres- 

j sion  of  the  query  compatible  with  the  contents  of  the  data  base.  Follow- 

ing any  such  translation,  if  required,  the  Primary  Hit  Resolution  Module 
j (PHRM)  examined  the  query  constraints  and  the  inverted  files  associated 

with  the  data  base  to  be  accessed  to  identify  those  records  that  satisfied 
the  query  constraints  and  contained  the  data  elements  requested.  The  keys 
for  these  records  were  written  to  a temporary  file  and  passed  to  the  ADS' 
Interface  Module,  which  accessed  the  appropriate  data  base,  retrieved  the 
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requested  data  values,  and  formatted  those  values  into  "response"  records. 

The  response  records  generated  at  the  executive  site  (DPSCPAC)  were 
written  directly  to  a temporary  Response  File.  The  response  records 
generated  at  a remote  site  (NMCSA)  were  passed  to  the  NAVLIS  Telecommuni- 
cations Subsystem  (NTS)  for  queuing  until  all  responses  had  been  generated. 
The  queue  was  then  transmitted  to  the  executive  site  where  it  was  appended 
to  the  Response  File.  This  file,  which  now  contained  all  the  data  retrieved 
to  answer  the  user's  query,  was  manipulated  by  the  Sort  Module  (SM),  if 
the  user  has  specified  a sort  sequence  for  his  output.  The  Report 
Generator  Module  then  accepted  the  sorted  response  records  and  formated 
the  output  according  to  either  a default  format  or  a pre-defined  report 
format  specified  with  the  query. 


5.2  "DEVELOPMENT"  NAVLIS  PILOT  SYSTEM 

The  NAVLIS  Pilot  Model  under  development  at  project  termination  was 
essentially  the  executable  system,  described  briefly  above,  with  sig- 
nificant additional  capabilities.  The  Pilot  Model  was  in  the  process  of 
being  expanded  from  a two-node  network  (DPSCPAC  and  NMCSA)  to  a three- 
node  network  with  the  addition  of  the  Data  Processing  Service  Center  for 
the  Atlantic  (DPSCLANT)  in  Norfolk,  Virginia.  DPSCLANT  was  to  be  a 
second  "executive"  site,  so  that  a user  could  make  a terminal  connection 
at  DPSCLANT  or  DPSCPAC,  whichever  was  most  convenient.  Each  of  these 
two  sites  was  to  have  the  full  range  of  executive  capabilities  (a  through 
1 above)  and  could  retrieve  data  locally  or  from  either  or  both  of  the 
other  two  facilities  (NMCSA  and  DPSCPAC,  or  NMCSA  and  DPSCLANT).  When 
either  DPSCPAC  or  DPSCLANT  was  to  perform  the  executive  function  for  a 
particular  query,  the  system  would  recognize  that  condition  and  insure 
that  the  other  executive  site  performed  only  the  satellite  or  remote 
site  range  of  functions  for  that  query.  For  example,  if  the  user  made 
a terminal  connection  to  DPSCLANT  and  input  a query  that  accessed  data 
bases  at  both  NMCSA  and  DPSCPAC,  the  DPSCPAC  software  would  recognize 
that  only  the  remote  site  functions  (synonym  resolution,  hit  resolution, 
and  data  retrieval)  were  to  be  performed  for  this  query,  and  that  the 


executive  type  functions  (query  translation,  report  generation,  etc.) 
were  being  performed  by  another  node  in  the  system.  The  development 
of  the  multi-executive  capability  in  the  network  would  have  provided 
much  greater  flexibility  in  determining  the  location  of  sites  that  could 
most  efficiently  control  the  the  system  retrieval  operation. 

As  mentioned  previously,  both  the  data  bases  accessible  by  the 
"executable"  NAVLIS  system  were  supported  by  data  management  systems 
(DMS's).  With  the  addition  of  DPSCLANT  to  the  network,  a non-DMS 
supported  data  base  would  have  become  accessible  through  the  system. 

The  project's  intention  was  to  mount  the  DPSCLANT  counterpart  to  the 
DPSCPAC  APPMS  data  base  as  an  indexed  sequential  file.  As  an  ISAM 
data  base,  the  application  programs  that  were  currently  processing 
the  file  sequentially  could  continue  to  do  so.  Additionally,  the 
NAVLIS  system  could  have  accessed  the  file  randomly.  This  completed, 

NAVLIS  would  have  been  able  to  demonstrate  the  ability  to  access  a data  base 
supported  by  a compatable  DMS  (SHARP),  to  interface  with  and  access  a data 
base  supported  by  a noncompatible  DHS  (IMS),  and  to  interface  with  and  access 
a non-DMS  supported  data  base,  simultaneously,  at  remote  locations,  in 
response  to  the  same  query. 

The  secondary  his  resolution  capability  was  to  be  incoroorated  into 
the  system  concurrently  with  the  addition  of  DPSCLANT  to  the  network.  This 
capability  would  have  permitted  the  user  to  query  on  anv  data  element  in  the 
system,  regardless  of  whether  that  element  had  been  selected  for  inversion 
(without  the  user  having  to  know  which  elements  were  inverted  and  which  were 
not).  This  capability  is  found  in  few  data  management  systems.  Further 
discussion  of  the  secondary  hit  resolution  capability  can  be  found  in 
Aooendix  A.  At  project  termination  the  "executable"  version  of  the  system 
included  only  the  primary  hit  resolution  capability,  which  reouired  all  the 
query  constraints  to  be  on  inverted  data  elements.  Retrieval  of  information, 
however,  could  be  performed  on  both  inverted  and  non-inverted  data  elements. 
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Several  of  the  development  modules,  the  ADS  Interface  Module  and 
the  Primary^Hit  Resolution  Module  in  particular,  had  underqone  significant 
modification  allowing  them  to  process  considerable  faster  and  more 
efficiently  than  their  "executable"  system  counterparts.  Several  other 
system  efficiencies  had  been  incoroorated  into  the  development  module, 
along  with  corrections  to  coding,  design,  and  data  errors  discovered  while 
testing  the  "executable"  system.  All  the  capabilities  discussed  above 
were  due  for  implementation  in  the  NAVLIS  Pilot  Model  within  two  to 
three  months  of  the  date  on  which  the  project  termination. 
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6.  NAVLIS  MANAGEMENT  CONSIDERATIONS 


The  technical  aspects  of  the  NAVLIS  project  (developing  a logical 
development  sequence  from  pilot  model  to  proposed  implementation) 
represented  but  a portion  of  the  task  of  successfully  applying  and 
implementing  such  a system. 

The  management  of  a NAVLIS-type  application  would  be  critical  to 
its  ultimate  effectiveness.  The  experience  gained  from  developing  the 
NAVLIS  Pilot  network,  even  though  that  work  was  not  completed,  suggested 
the  following  managerial  considerations: 

a)  the  management  of  a NAVLIS  would  require  a staff  of 
logisticians  and  systems  analysts  at  the  Headquarters 
(OP-91,  OP-04)  level  to  make  policy  and  set  priorities. 

b)  at  least  two  analysts,  with  joint  responsibility  for 
assuring  that  NAVLIS  files  and  software  were  kept 
operational,  would  be  required  at  each  network  site. 

c)  stringent  software  configuration  control  procedures, 
such  as  the  ones  employed  during  the  NAVLIS  pilot 
development,  would  have  to  be  initiated. 

d)  a User  Assistance  Group  would  be  required  to  process 
user  requests  for  system  changes  and  to  educate  new 
users. 

e)  standardization  of  nomenclature  among  data  systems 
for  use  in  describing  like  data  elements  would  be  use- 
ful, if  not  necessarily  a requirement. 

f)  primary  and  secondary  sources  of  similar  information 
would  have  to  be  identified  and  incorporated  into  an 
intelligent  data  directory. 

g)  user  access  procedures  and  restrictions  would  have  to 
be  developed  at  the  file,  record,  and  data  element 
levels  to  safeguard  confidential  information  (data). 
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h)  built-in  safeguards  to  protect  against  the  construction 

of  classified  information  from  segments  of  data  obtained  from 
various  data  sources  would  have  to  be  inserted  in  the 
control  software, 

i)  control  of  updating  procedures  and  cycles  would  have 

to  be  imposed  to  assure  the  consistency  of  data  throughout 
the  network. 
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■'  7.  SUMMARY  OF  PROJECT  EXPENDITURE  BY  DTNSRDC 

The  following  is  an  outline  of  the  expenditures  and  purposes  for 
those  expenditures  on  the  NAVLIS  project  since  its  transfer  to  DTNSRDC 
in  FY  73. 

7.1  FISCAL  YEAR  1973  EXPENDITURES 
Total  Funding  - $60K 

Expendi tures 

Amount  Purpose 

$31. 8K  - Labor/Overhead  (DTNSRDC-Inhouse) . Review 
and  evaluate  current  status  of  NAVLIS  and 
make  recommendations  as  to  its  disposition 
i and  direction. 

.5K  - Misc:  (Computer,  Report  Publishing,  etc.) 

^ 10.5K  - Contract  to  ManTech  of  N.  J.  to  organize 

and  classify  NAVLIS  Technical  Library. 

* 17. 2K  - Return  to  NELC 

, Total  $60. OK 

t 

\ 7.2  FISCAL  YEAR  1974  EXPENDITURES 

[ Total  Funding  - $312K 

t 

i 

) Expenditures 

I Amoujit  Purpose 

I $160. IK  - DTNSRDC  - Inhouse 

Develop  Preliminary  Design  Spec  for  NAVLIS 
Executive.  Program  Management,  Pilot  Con- 
^ figuration  Determination. 

14. 6K  - Computer  Charges/Travel 

8.5K  - NELC  to  digitize  CDDB  for  Transfer  to  DTNSRDC 

49. 6K  - ManTech  of  N.  J. 
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69. 7K  - 

Rockwell  International:  for  Scenario 
Development  Detail  Functional  Spec  for 
Selected  Executive  and  T/P  modules. 

25. OK  - 

Data  Processing  Services  Center  - 
Two  months  of  hardware  upgrade  rental 
in  preparation  for  NAVLIS  development 
and  participation. 

Total  $327. 4K 

7.3  FISCAL  YEAR  1975  EXPENDITURES 
Total  Funding  - Sl.OllM 


Expendi tures 
Amount 

Purpose 

$354. 2K  - 

In-house  DTNSRDC,  Pilot  Executive  $oftware 
Development,  Exec.  Control  Module,  Query 
Translation  Module,  Sort  Module,  Primary 
Hit  Resolution  Module,  Report  Definition 
Module,  Report  Generation  Module,  etc. 

10. 8K  - 

Prior  Commitment  (Rockwell  SPCC) 

59. 5K  - 

Computer  Time  and  Travel 

3.6K  - 

Returned  to  Sponsor 

48. OK  - 

DPSCLANT,  Hardware  upgrade  to  prepare 
for  Pilot  participation 

5. OK  - 

Naval  Weapons  Engineering 
Support  Act.;  Scenario  Dev. 

2.3K  - 

NMCSA,  Rental  of  Sync.  Line  Adaptor 
to  allow  use  of  TSO  in  360/370  Software 
development. 

108. 2K  - 

NAVCOSSACT,  NAVLIS  TELCOM 
Subsystem  Development,  CPU-to-CPU 
Software 

215. OK  - 

DPSCPAC  S150K  Hardware  Rental 
65K  Software  Support 

6. OK  - 

SPCC  Mi  sc  request  S-M 

Data  File  Generation 
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55. 2K 


Rockwell  Int'l 


Data  Analysis  Module  Spec 
Self  Management  Module  Spec 
CINCPAC  Requirements  Analysis  Spec 

: 

30. OK  - 

Withdrawn  by  Sponsor 

15. 4K  - 

Deficit  from  FY  74 

1 

1 

103. 3K  - 

ManTech  of  N.  J. 
Cost/Benefit  Methodology 

1 

1 

1 

Total  1016. 5K 

7.4  FISCAL  YEAR  1976  EXPENDITURES 

! j 

Total  Funding  - 

$1 .040M 

Expend! tures 

! 

Amount 

Purpose 

, 1 

$ 95K 

NAVCOSSACT,  T/P  Support 

Pilot  Network  between  DPSCPAC  and  NMCSA 

T/P  Alternatives  Study 

13. OK  - 

NAVCOSSACT  (NAVTELCOM) 
TELCOM  COMPUTER  COSTS 

< 

t 

75. OK  - 

DPSCPAC,  Hardware 

Rental,  Analyst  Support  (minimal) 

i 

75. OK  - 

DPSCLANT,  Hardware 
Upgrade  Rental 

1 

.2K  - 

CINCLANTFLT,  TELCOM 

\ 

I 1 

Cost  for  NAVLIS  Appl . 

5. OK  - 

FMSO,  3M  Data 

i 

Generation 

11. 6K  - Rockwell  International  (Prior  year  adjustment) 

12. OK  - General  Electric  Software  Dev.  Support 

55. OK  - ManTech,  CINCLANTFLT 
Requirements  Analysis 
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241. 6K 
42K 

414. 6K 
Total  1040. OK 


In-house  DTNSRDC  Software  Development 

Final  Program  Documentation 
Recommendations/ Spec. 

Returned  to  Sponsor  upon  project 
termi nation 


i 

I 

i 
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8.  TECHNICAL  CONSIDERATIONS  AND  RECOMMENDATIONS 


This  section  of  the  report  will  identify,  through  recommendations, 
areas  in  which  the  NAVLIS  concept  could  have  proven  beneficial  to  the 
Navy,  and  will  indicate,  through  considerations,  several  benefits  and 
problems  associated  with  system  design  characteristics  unique  to  a 
NAVLIS-type  effort. 

8.1  CONSIDERATIONS 

The  consideratjonj^  discussed  here  touch  on  the  salient  aspects  of 
the  NAVLIS  technical  effort  in  the  Executive  Subsystem.  The  techincal 
considerations  are  as  follows: 

8.1.1  GENERALIZED  "ADS  INTERFACE"  CONSIDERATIONS 

Of  particular  concern,  early  in  the  design  phase  of  the  NAVLIS 
system,  were  the  difficulties  posed  by  the  requirement  to  read  multiple 
data  bases  of  dissimilar  format  and  organization.  The  data  files 
identified  as  likely  candidates  for  NAVLIS  access  included  sequentially 
organized  files  designed  for  and  operating  in  a batch  processing  mode, 
as  well  as  data  files  maintained  by  large  and  powerful  data  management 
systems  with  their  sophisticated  data  base  structures.  The  effort  and 
overhead  associated  with  generating  unique  software  programs  to  access 
and  extract  data  from  each  of  the  data  files  to  be  included  in  the  system 
appeared  to  be  excessive.  However,  the  feasibility  of  developing  a 
single  program  capable  of  accessing  all  the  systems  data  bases  was 
questionable.  Since  the  initial  NAVLIS  efforts  would  be  dealing  with 
a limited  number  of  data  bases,  the  option  to  develop  a unique  program 
(the  ADS  Interface  Module)  to  interface  the  system  with  each  data  file 
was  selected.  It  was  anticipated  that  the  experience  gained  by  inter- 
facing each  data  base  with  its  own  module  would  provide  some  bases  for 
determining  whether  a generalized  ADS  Interface  Module  was  feasible 
and/or  practical . 
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The  two  most  important  functions  of  the  ADS  Interface  Module  are 
to  read  records  from  its  associated  data  base  and  to  extract  from 
those  records  the  data  values  requested  by  the  query.  Duritig  the 
development  of  the  module  to  accomplish  those  functions,  it  became 
apparent  that,  by  using  table  structures  and  subroutines,  a generalized 
ADS  Interface  Module  was  feasible  and  would  be  more  practical  than  the 
file  structure  dependent  versions  which  had  been  used  for  system  develop- 
ment. The  ADS  modules  currently  use  a table  structure  to  define  the 
format  of  the  data  record.  For  each  data  field  that  can  be  retrieved 
from  the  record,  the  table  contains  an  entry  that  indicates  the  position 
of  the  first  character  in  the  field  and  the  number  of  characters  in  the 
field.  For  fixed  length/fixed  field  records,  this  information  remains 
constant  throughout  module  execution.  For  variable  length  records  and 
fields,  the  positional  information  is  entered  in  the  table  after  each 
record  is  read  and  before  value  retrieval  has  begun.  The  data  required 
to  determine  the  location  of  each  field  in  the  record  is  normally  contained 
in  a fixed  segment  of  the  record  itself.  Data  files  containing  multiple 
record  types,  each  with  a unique  format,  present  no  problem  other  than 
the  need  for  multiple  tables  to  define  each  record  type. 

To  generalize  the  ADS  Interface  Module,  a file  could  be  constructed 
at  each  site  in  the  network  containing  the  record  format(s)  (in  terms  of 
field  positions  and  lengths)  for  each  data  file  to  be  accessed  at  that 
site.  Prior  to  accessing  a specific  data  base,  the  information  needed 
to  complete  the  table  that  defines  the  record  structure  of  the  data  base 
would  be  read  from  the  file  of  record  formats  at  that  location.  This 
represents  a significant  step  toward  ADS  Interface  Module  generalization 
by  removing  the  necessity  for  hard-coded  record  descriptions  in  the  module. 

The  statements  required  by  the  ADS  Interface  Module  to  actually 
perform  the  read  function  may  differ  significantly  as  a result  of  the 
access  method  employed,  the  record  key  specifications,  and  the  data 
management  system,  if  any,  supporting  the  file  to  be  read.  By  assigning 
the  reading  process  to  a unique  subroutine,  the  ADS  Interface  Module 
achieves  another  level  of  generalization.  All  file  peculiar  processes 
related  to  the  read  function  could  be  performed  by  these  subroutines. 


e.g.,  opening  and  closing  the  file,  error  conditions,  and  end-of-file 
conditions.  Other  file  peculiar  functions  directly  associated  with 
the  reading  of  the  record,  such  as  those  that  would  be  available  through 
a data  management  system,  would  be  concentrated  in  the  subroutine 
associated  with  the  data  file  to  be  accessed.  Functions  performed  by 
a subroutine  that  accessed  a file  supported  by  IMS,  for  example,  would 
include  modifying  the  "GET"  operator  in  the  IMS  "CALL"  statement  to 
effect  the  desired  type  of  segment  retrieval. 

An  additional  area  of  processing  that  is  file  peculiar  involves 
data  value  conversions.  Although  NAVLIS  requires  no  data  alteration 
on  a file  to  be  accessed,  there  are  conditions  in  which  a retrieved 
value  must  be  converted  to  a common  system  form  of  representation. 

A NAVLIS  "standard"  is  required  to  achieve  a degree  of  output  consistency, 
as  well  as  to  permit  arithmetic  operations  on  retrieved  data.  For 
example,  quantities  fof'  the  same  item  may  be  recorded  in  different 
units  of  measure  on  different  data  files.  The  discrepancy  of  recording 
quantities  in  tens  of  units  and  hundreds  of  units  must  be  resolved  for 
both  consistency  of  display  and  data  manipulation.  In  many  cases,  the 
conversions  required  are  unique  to  a specific  data  file  at  a site. 

Such  file  peculiar  conversions  could  be  performed  by  the  subroutine 
that  executes  the  access  functions  for  that  data  file.  When  several 
files  at  one  site  require  the  same  type  of  conversion  for  some  of  their 
data  values,  e.g.,  Julian  date  conversion,  the  coding  required  to  perform 
that  function  could  be  included  in  the  ADS  Interface  Module. 

In  short,  the  degree  of  commonality  that  emerged  among  the  ADS 
Interface  Modules  developed  for  the  NAVLIS  Pilot  Model  suggests  that 
a unique  interface  module  for  each  data  file  is  not  a requirement. 

A considerably  more  efficient  approach  would  be  to  utilize  a single 

ADS  Interface  Module  to  perform  common  functions,  e.g.,  determining 

data  elements  to  be  retrieved,  generating  response  records,  interfacing  ’ 

with  the  control  module  (ECM  or  RCM),  performing  common  conversions, 

etc.,  and  to  use  subroutines  for  file  accessing  and  file  peculiar  data  < 

conversions.  A critical  feature  for  this  approach  would  be  a system 

support  file  accessable  to  the  ADS  Interface  Module  containing  the  record  ^ , 

• i 
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format  data,  expressed  as  data  field  starting  positions  and  lengths. 

The  generalized  module  would  then  execute  by  reading  the  support  file 
and  initializing  the  record  format  table  with  the  entries  describing 
the  records  on  the  data  file  to  be  accessed.  The  ADS  Interface  Module 
would  execute  those  functions  common  to  all  data  retrieval  regardless 
of  the  data  file  being  accessed,  and  call  subroutines  to  execute  file 
peculiar  accesses  and  conversions. 

8.1.2  SYNONYM  RESOLUTION  CONSIDERATIONS 

In  the  development  of  both  the  San  Diego  demonstration  and  the 
Pilot  model,  some  of  the  difficulties  of  dealing  with  nonstandardized 
data  elements  were  readily  apparent.  Much  of  the  disparity  could  be 
rectified  by  performing  conversions  as  data  were  extracted  from  the 
record.  For  example,  Gregorian  or  Julian  date  conversions  are  easily 
performed  by  a small  number  of  programming  statements.  The  conversion 
of  units  of  measure  to  some  internal  system  standard  is  also  performed 
easily. 

Whenever  a definable  and  consistent  algorithm  can  be  applied  to 
translate  the  value  being  extracted  from  the  data  file  to  an  internal 
standard  representation,  the  conversion  required  can  be  performed  with 
little  difficulty  (assuming  a reasonable  algorithm).  However,  when  an 
algorithm  cannot  be  defined  to  perform  a required  conversion,  the 
problem  becomes  more  complicated. 

This  situation  presents  itself  when  different  data  files  use 
different  conventions  for  identification  of  the  same  item.  A ship, 
for  example,  may  be  identified  by  name  in  one  data  file,  by  UnjJ: 
Identification  Code  (UIC)  in  another  file,  and  by  Permanent  Unit  Code 
(PUC)  in  a third  file.  The  problem  is  complicated  further  when  the 
file  using  the  name  of  the  ship  for  identification  has  no  established 
procedures  for  recording  that  value,  or  when  the  procedures  are 
established  but  not  followed.  As  a result,  the  "ship  name"  field  may 
contain  several  different  values  referring  to  the  same  vessel,  i.e., 
U.S.S.  Midway,  USS  Midway,  Midway.  Assuming  a query  is  to  be  generated 
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requesting  data  related  to  a specific  ship,  the  terminal  operator  could 
identify  that  ship  by  any  of  the  above  types  of  value  or  by  an  entirely 
different  value  type,  e.g.,  the  ship's  hull  number. 

In  a retrieval  system  capable  of  accessing  multiple  data  files,  all 
data  relevant  to  the  query  should  be  retrieved  regardless  of  different 
identification  conventions.  Both  the  Pilot  model  and  the  San  Diego 
demonstration  addressed  this  problem  through  the  use  of  the  Synonym  Reso- 
lution Module  (SRM).  A Synonym  Resolution  File  was  created  for  each  data 
file  to  be  accessed  and  was  to  contain  the  item  identifications  as  they 
were  recorded  on  the  associated  data  file.  To  continue  the  example 
above,  if  "Ship  Name"  was  the  field  of  concern,  the  Synonym  Resolution 
File  would  contain  each  ship  name  that  appeared  on  the  data  file. 

Associated  with  each  ship  name  on  the  Synonym  Resolution  File  would 
be  equivalent  identification  values,  and  their  type,  that  were  to  be 
accommodated.  The  Synonym  Resolution  File  would  then  indicate  the 
equivalency  of  "Ship  Name",  "UIC",  "PUC"  and  "Hull  Number"  as  data 
types  for  ship  identification,  and  would  also  indicate  what  specific 
value  in  each  type  would  identify  a particular  ship.  This  relationship 
would  be  indicated; 

USS  ABCD  (SHIPNAME)  = 12345  (UIC)  = 67890  (PUC)  = ABC-12  (HULL  NO.) 

Using  the  Synonym  Resolution  File,  the  SRM  translates  the  query  input 
into  the  equivalent  data  type  and  values  necessary  to  access  the 
associated  data  file.  If  a data  file  identifying  ship  by  UIC  code  is 
to  be  accessed,  a query  input  of 

IF  SHIP-NAME  IS  USS  MIDWAY 

would  be  translated  by  the  SRM  to  the  internal  system  equivalent  of 

IF  UIC  IS  03341 

The  same  translation  is  performed  for  data  requested  by  the  query. 

PRINT  SHIP-NAME  becomes  PRINT  UIC 

In  the  Pilot  Model  and  the  San  Diego  demonstration,  the  SRM  capabil- 
ity was  used  to  translate  ship  names,  organization  names,  and  aircraft 
squadron  designations  to  their  equivalent  UIC  and  PUC  codes  and  vice  versa. 
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Also  accommodated  were  various  permutations  of  names  and  designators  to 
allow  the  user  more  flexibility  in  query  formulation.  For  example, 
equivalency  was  established  between  "COMNAVAIRPAC"  and  "CNAP",  and 
between  "CVA-41"  and  "CVA  41".  Care  was  taken  to  select  commonly  used 
abbreviations  and  permutations  to  prevent  the  size  of  the  Synonym  Resolu- 
tion File  from  becoming  too  large. 

The  SRM  was  partially  successful  in  enabling  access  to  multiple  data 
files  despite  encountering  different  values  for  identification  of  the 
same  item.  At  project  termination  the  SRM  performed  only  the  synonym 
resolution  required  to  access  the  data  file;  the  module  did  not  translate 
the  retrieved  value  into  what  the  user  had  originally  requested.  If  a 
user  had  requested  the  retrieval  of  a ship's  name  from  a particular  data 
file  and  ships  were  identified  in  that  file  by  UIC  code,  that  code  would 
be  retrieved  and  displayed  to  the  user.  If  synonym  resolution  is  to  be 
performed,  it  would  be  beneficial  to  translate  the  data  retrieved  into 
the  form  originally  requested  by  the  user,  or  to  advise  the  user  that 
synonym  resolution  had  occurred  and  identify  the  values  being  retrieved, 
e.g.,  names,  codes,  etc. 

Although  informing  the  user  of  the  translation  that  has  occurred  is 
beneficial,  it  does  not  overcome  certain  problems  inherent  in  the  sub- 
stitution of  one  value  for  another,  especially  as  the  sophistication  of 
the  query  increases.  One  such  difficulty  becomes  apparent  when  a query 
specifies  the  retrieval  of  ship  name,  as  well  as  other  values,  from 
records  that  satisfy  the  query  constraints  and  also  requests  that  the 
output  be  sorted  on  ship  name.  When  codes  are  retrieved  from  one  file 
and  names  from  another,  the  execution  of  the  sort  is  not  likely  to 
produce  the  result  the  user  had  intended. 

When  the  query  language  used  allows  the  user  to  specify  "prefix", 
"suffix"  or  "partial"  value  searches,  as  did  the  NAVLIS  Pilot  Module, 
the  substitution  of  a different  value  as  a result  of  synonym  resolution 
can  produce  meaningless  results.  Similarily,  the  use  of  such  conditions 
as  "greater  than"  and  "less  than"  can  present  problems.  In  this  case, 
the  substitution  of  an  alphabetic  name  value  for  a numeric  code  value 


53 


could  conceivably  produce  retrieval  of  data  elements  from  every  record 
on  the  data  file. 

The  problem  of  synonym  resolution  is  a difficult  one  when  trying 
to  allow  simultaneous  access  to  multiple  data  files.  Whenever  possible 
the  system  should  resolve  differences  in  identification  conventions 
between  files  without  requiring  the  user  to  input  several  values. 

However,  the  system  should  also  be  able  to  determine  when  value  substi- 
tution may  produce  meaningless  or  erroneous  results. 

Further  development  of  the  synonym  resolution  capability  should 
attempt  to  solve  these  problems.  It  is  probable  that  an  examination  [ 

of  the  query  structure  by  the  SRM  could  identify  most  cases  in  which 
value  substitution  might  not  produce  the  intended  results.  The  module  i; 

might  then  begin  a dialogue  with  the  user  identifying  the  problem  and  i 

potential  hazards  and  alternatives,  if  anv.  j 

"I 

■' 

8.1.3  APPLICATIONS  VS  AD  HOC  QUERIES  CONSIDERATIONS 

Much  of  the  emphasis  during  NAVLIS  system  design  and  development 
was  placed  upon  the  ability  of  the  system  to  respond  to  ad  hoc  queries 
generated  by  logistics  managers.  This  emphasis  was  a natural  result  of 
the  "demonstration"  oriented  growth  of  the  system.  The  capability  to 
respond  to  such  queries  is  an  important  one,  but  an  equally  important  -j 

capability  is  in  using  the  simultaneous,  remote  multi-file  access  j 

facility  to  perform  regular  and  repeated  applications  processing.  il 

At  project  termination  an  effort  was  underway  to  develop  an  application 
package  for  ship  maintenance  and  repair  for  CINCLANTFLT.  Earlier  in 
the  NAVLIS  project,  a demonstration  of  the  usefulness  of  this  type  of 
system  in  solving  existing  reporting  and  operational  problems  was  j 

requested  by  COMNAVAIRPAC.  In  conjunction  with  logistics  managers  | 

and  Data  Processing  Service  Center  - Pacific  (DPSCPAC)  personnel,  the  | 

Aviation  Consolidated  Allowance  Test/Fleet  Program  Support  Material 
(AVCAL/FPSM)  problem  was  identified  as  relevant  to  a NAVLIS  type  system.  * 

This  experiment  is  documented  in  detail  in  "Experiment  Documentation  ^ 

for  San  Diego  Demonstrations"  produced  by  Rockwell  International  on 
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28  June  1973.  Briefly,  however,  the  problem  involved  determining 
additional  spare  part  support  requirements  at  NSD  Subic  Bay  when  the 
weapon  system  of  an  aircraft  carrier  in  the  western  Pacific  changed 
by  aircraft  quantity,  configuration,  or  type.  At  that  time,  and 
undoubtedly  at  this  writing  (two  and  a half  years  later)  the  process 
for  solving  that  problem  involved  mailing  three  magnetic  tapes  from 
ASO,  Mechanicsburg,  to  DPSCPAC  where  a series  of  tape  conversions 
and  batch  programs  was  run  to  produce  a card  deck.  The  card  deck 
was  then  mailed  to  NSD  Subic  for  processing  and  production  of  another 
card  deck  and  a report  which  were  mailed  to  AIRPAC  and  SERVPAC,  respec- 
tively. When  additional  procurement  was  required  and  approved  by 
SERVPAC,  AIRPAC  and  NSD  Subic  were  notified  by  mail.  This  process 
required  anywhere  from  days  to  weeks  with  all  the  attendent  problems 
of  tape  and  card  handling  and  mailing.  In  an  attempt  to  show  how  the 
operation  could  be  performed  in  a NAVLIS  environment,  the  facilities 
involved  were  simulated  on  a commercial  time  sharing  network  and  subsets 
of  the  operational  data  files  were  mounted  on  that  network.  With  the 
capabilities  inherent  in  a NAVLIS-type  system  to  initiate  processing 
at  remote  facilities,  retrieve  data  from  remote  facilities  to  be  used 
as  input  to  local  processing,  and  transmit  output  to  other  remote 
locations,  an  AVCAL/FPSM  problem  could  be  solved  in  several  minutes  or 
hours  depending  upon  the  complexity  of  the  problem. 

When  data  from  another  location  are  needed  to  perform  some  reporting 
or  operational  function,  the  typical  process,  as  with  the  AVCAL/FPSM 
example,  is  to  copy  and  mail  tapes  from  one  site  to  another  periodically. 
In  some  instances,  copies  of  files  or  subsets  of  files  are  sent  to 
several  locations  for  processing.  When  this  process  involves  a data 
base  that  is  subject  to  much  change,  the  mailing  must  be  frequent  or 
the  data  rapidly  become  obsolete.  A considerably  more  efficient  approach 
would  be  to  retrieve  only  the  data  necessary  for  a specific  process  and 
only  when  that  process  is  to  be  executed. 

For  example,  assume  multiple,  service-wide  reporting  and  operational 
requirements  that  utilize  3M  data.  Currently,  facilities  satisfy  that 
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requirement  by  requesting  copies  of  certain  subsets  of  the  3M  data  base, 
or,  more  frequently,  by  creating  and  maintaining  their  own  subset  of  3M 
data.  The  first  alternative  creates  an  additional  workload  for  3M  data 
base  personnel  and  provides  the  user  with  data  that  daily  become  more 
obsolete.  The  second  alternative  usually  involves  maintaining  a copy 
of  data  input  to  3M,  generating  additional  work  for  personnel  at  the 
user's  facility  and  contributing  to  multiple  copies  of  the  same  data. 

If  users  could  retrieve,  during  or  just  prior  to  program  execution, 
only  the  data  relevant  to  the  program  from  a single  master  data  base, 
the  problem  of  obsolete  data,  duplicate  data  bases,  duplicate  data  base 
maintenance  efforts,  and  additional  workload  at  both  facilities  would 
be  alleviated. 

The  NAVLIS  system  held  the  promise  of  accomplishing  these  objectives. 
Among  the  NAVLIS  goals  were  the  capability  to  pre-program  the  remote 
retrieval  of  specific  data  elements  from  both  local  and  remote  data  bases, 
and  the  ability  to  generate  temporary  files  from  that  retrieved  data 
for  input  to  local  programs,  to  initiate  specified  programs  automatically, 
and  to  transmit  output  to  local  and  remote  terminals.  This  combination 
of  capabilities  would  enable  request  submission,  data  input,  program 
processing,  and  output  printing  to  be  done  at  four  different  locations, 
if  required. 


8.1.4  USER  PARTICIPATION  IN  RETRIEVAL  SELECTION  CONSIDERATIONS 

The  NAVLIS  objective  of  providing  simultaneous  access  to  multiple 
data  bases  at  several  geographically  remote  facilities  immediately 
presented  problems  concerning  the  control  of  the  retrieval  process. 
Requiring  the  user  to  be  aware  of  which  facilities  and  which  data  bases 
contained  the  values  necessary  to  respond  to  his  query  was  unacceptable. 
At  the  same  time,  without  the  capability  to  restrict  the  search  under 
certain  conditions,  the  volume  of  response  data  could  become  unmanage- 
able. During  NAVLIS  Pilot  Model  development  and  testing,  programmers 
and  analysts  who  were  well  acquainted  with  system  capacities  and  data 
base  contents  inadvertently  generated  queries  whose  responses  overflowed 
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the  system's  files.  The  problem  would  become  significantly  more  acute 
with  users  unfamiliar  with  the  contents  of  the  data  bases  in  the  network. 
Some  provisions  for  limiting  the  search  area  at  query  time  and  for 
detecting  and  preventing  impending  overflow  conditions  were  mandatory. 

The  NAVLIS  Pilot  Model  currently  has  the  capability  of  determining, 
without  user  intervention,  those  data  files  that  could  satisfy  the  user's 
query  and  of  performing  data  retrieval  from  those  files.  Early  in  the 
NAVLIS  design  phases  it  was  recognized  that  some  system  users  would  be 
sophisticated  enough  to  identify  a subset  of  the  system's  data  bases 
that  was  relevent  to  their  query.  A capability  was  provided,  therefore, 
to  allow  the  user  to  enter  certain  descriptions  or  parameters  prior  to 
the  selection  of  candidate  data  bases  by  the  system  software.  When  such 
parameters  are  input  by  the  user,  e.g.  "AIRCRAFT",  "FIRST  FLEET", 
"MAINTENANCE",  etc.,  only  the  data  bases  satisfying  those  parameters 
are  considered  for  retrieval. 

Parameters  describing  the  types  of  data  contained  in  a base  were 
manually  assigned  when  the  data  base  was  incorporated  into  the  network. 

The  name  of  the  data  base  was  also  one  of  the  parameters  assigned 
enabling  a user  to  designate  a specific  file(s)  for  retrieval.  (A  bene- 
ficial enhancement,  not  currently  a feature  of  the  Pilot  Model,  would 
be  to  identify  to  the  user  those  data  bases  that  satisfied  his  parameters 
and  allow  the  user  to  accept  or  modify  the  list  of  candidate  data  bases 
or  input  a new  set  of  parameters  if  desired).  This  capability  would  provide 
some  user  control  of  the  retrieval  process,  but  assumes  some  knowledge 
of  file  content  by  the  user,  and  still  provides  no  guarantee  against 
excessive  retrieval. 

Although  the  data  bases  that  might  satisfy  the  user's  query  are 
identified  early  in  the  processing  cycle  (by  the  File  Selection  Module), 
not  until  after  hit  resolution  has  been  performed  is  there  an  indication 
of  the  amount  of  data  that  will  be  retrieved  from  a data  base  to  respond 
to  the  query. 

The  current  Pilot  Module  is  subject  to  file  overflow,  by  exceeding 
allocated  internal  table  capacities,  and  program  termination  in  several 
areas: 
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1)  Hit  File  overflow  - as  the  Primary  Hit  Resolution  Module 
(PHRM)  determines  which  records  in  a data  base  satisfy 
the  user's  query,  the  access  key  of  each  "hit"  record  is 
written  to  the  Hit  File. 

2)  Teleprocessing  Message  Queue  overflow  - as  the  ADS  Inter- 
face Module  at  a remote  site  generates  response  records 
(one  response  record  for  each  data  element  requested  and 
contained  in  each  hit  record),  they  are  passed  to  the 
teleprocessing  module  for  queuing  until  all  responses 
for  that  site  have  been  generated.  After  all  retrieval 
has  been  completed  at  a remote  site,  the  response  records 
produced  are  transmitted  to  the  query  site. 

3)  Response  File  overflow  - the  response  records  generated 
by  ADS  Interface  Modules  at  the  user's  site  are  written 
directly  to  the  Response  File  (no  teleprocessing  of  this 

! data  is  necessary).  In  addition,  all  the  response  records 

generated  by  and  transmitted  from  remote  sites  are  written 
to  the  Response  File. 

For  each  of  the  conditions  above,  it  is  possible  to  determine  before- 

' hand  that  an  overflow  will  occur  and  to  initiate  procedures  to  prevent 

? the  overflow.  The  Primary  Hit  Resolution  Module  need  only  be  provided 

with  the  maximum  capacity  of  the  Hit  File  and  be  asked  to  monitor  the 

i number  of  records  being  written  to  that  file.  On  detecting  an  impending 

* 

i overflow  condition,  the  module  could  suspend  normal  processing  while 

j determining  what  preventive  action  to  take.  The  user  should  be  advised, 

i at  this  point,  that  at  least  one  data  base  to  be  accessed  will  produce  a 

very  large  number  of  responses.  The  user  could  then  elect  to  exercise 
such  options  as  complete  query  cancellation,  partial  retrieval  from  the 
data  base  affected,  retrieval  from  data  bases  not  indicating  overflows 
only,  etc.  Procedures  should  also  be  developed  to  use  tape  files  to 
accept  the  Hit  File  overflow  if  the  user  elects  to  retrieve  all  response 
data  regardless  of  volume.  In  this  event,  procedures  to  prevent  overflow 
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conditions  on  the  teleprocessing  queue  and  the  Response  File  should 
automatically  be  initiated. 

Under  the  current  system  design,  all  response  records  generated 
from  the  data  base(s)  accessed  at  one  remote  site  are  queued  by  the 
teleprocessing  modules.  When  retrieval  from  all  data  bases  to  be 
accessed  at  a site  is  complete,  that  queue  is  transmitted  to  the  user's 
site.  Since  each  data  base  record  access  key  can  produce  multiple 
response  records  (one  response  record  is  created  for  each  data  element 
requested  by  the  query  for  each  "hit"  record  that  contains  those  data 
elements),  and  since  the  responses  from  multiple  data  bases  at  a site 
may  be  queued  before  transmission  begins,  the  teleprocessing  queue  could 
exceed  capacity  even  though  the  Hit  File(s)  involved  were  v/ell  within 
capacity.  This  condition  did  not  occur  during  Pilot  Model  development 
and  testing,  largely  because  queries  producing  an  excessive  amount  of 
retrieval  would  first  cause  a Hit  File  overflow  condition.  However, 
the  Hit  File  allocation  used  for  the  Pilot  Model  was  considerably  less 
than  would  be  required  for  a larger  system.  Additionally,  if  procedures 
are  incorporated  to  accept  Hit  File  overflow  and  continue  processing, 
then  procedures  for  accommodating  teleprocessing  queue  overflows  become 
mandatory. 

As  with  Hit  File  overflow,  the  use  of  a tape  file  back-up  to  accept 
teleprocessing  queue  overflow  is  a possibility.  A more  efficient  approach, 
however,  would  be  to  perform  multiple  transmissions.  As  the  teleprocess- 
ing queue  reaches  capacity,  response  record  generation  could  be  suspended 
while  data  on  the  queue  are  transmitted  to  the  user's  site.  After  the 
queue  is  emptied,  the  creation  of  the  response  records  can  continue. 

This  approach  provides  unlimited  response  record  handling  capacity  for 
the  teleprocessing  queue.  The  overflow  problem  then  moves  further  down- 
stream in  the  processing  cycle  to  the  Response  File. 

The  Response  File  in  the  Pilot  Model  resides  at  the  user's  site  and 
is  used  to  collect  all  responses  generated  for  the  query  at  all  sites. 

As  such,  it  is  a prime  candidate  for  overflow  problems,  especially  as 
procedures  are  developed  to  enable  the  Hit  File  and  teleprocessing  queue 
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to  accommodate  more  data.  As  with  the  Hit  File,  a tape  back-up  for  the 
Response  File  has  the  advantages  of  ease  of  implementation  and  large 
capacity. 

One  significant  enhancement  that  would  do  much  to  prevent  unwanted 
excessive  data  retrieval  would  be  to  advise  the  user  of  the  number  of 
hits  for  his  query  prior  to  data  retrieval.  Currently,  the  Pilot  Model 
advises  the  user  of  the  number  of  hits  and  provides  the  option  to  ter- 
minate the  query  prior  to  report  generation  but  after  the  response  data 
have  been  retrieved.  Ideally,  the  user  should-  be  notified  of  the  volume 
of  hits  determined  for  the  query  immediately  after  hit  resolution  has 
been  completed  and  before  retrieval  has  begun.  A Primary  Hit  Resolution 
Module  (PHRM)  resides  at  each  site  in  the  network.  The  module  executes 
only  once  for  each  query  and  determines  the  number  of  hits  from  each 
candidate  data  base  at  that  site.  Processing  for  that  query  could  be 
suspended  at  that  point  and  the  number  of  hits  for  each  data  base  at  that 
site  transmitted  to  the  control  module  at  the  user's  site.  PHRM  at  the 
user's  site,  if  that  site  has  data  bases  that  are  candidates  for  retriev- 
al, would  give  the  hits  per  data  base  directly  to  the  control  module. 

The  control  module  would  accumulate  the  hit  information  from  each  site 
and  present  it  to  the  user.  The  query  could  be  halted  at  this  point 
giving  the  user  the  option  to  terminate,  to  continue  with  the  hits  iden- 
tified, or  to  retrieve  data  from  selected  data  bases  only.  The  control 
module  would  then  notify  the  appropriate  sites  to  terminate  or  continue 
processing  as  specified  by  the  user. 

Whether  or  not  these  suggestions  for  control ing  data  retrieval  and 
file  overflow  survive  a more  extensive  analysis  of  alternate  methods, 
the  problem  of  inadvertent,  excessive  data  retrieval  must  be  addressed 
in  this  type  of  system.  As  the  network  expands  and  more  sites  and  data 
bases  are  added,  the  problem  becomes  more  acute. 

8.1.5  DATA  FILE  UPDATE  CONSIDERATIONS 

One  of  the  constraints  under  which  the  NAVLIS  Pilot  Model  was 
developed  was  that  operational  Navy  logistics  data  files  would  be  used 
without  altering  the  structure  of  those  files.  Most  of  the  data  files 


that  were  initially  to  be  incorporated  in  the  Pilot  Model  were  sequen- 
tially organized  data  files  designed  for  batch  processing.  The  NAVLIS 
approach  to  accommodating  data  files  with  no  existing  direct  access 
capability  was  to  place  those  files  on  disk  in  sequential  order,  generate 
inverted  files  (indexes)  to  logistics  data  elements  to  be  used  for 
direct  access,  and  modify  the  job  control  statement  for  applications 
programs  that  read  those  files  to  indicate  that  they  were  now  on  disk. 

In  addition  to  using  the  Indexed  Sequential  Access  Method  (ISAM),  or 
its  equivalent,  for  retrieval,  these  procedures  accomplished  the  objec- 
tives of  minimum  impact  on  both  existing  file  structures  and  applications 
programs  and  provided  a random  access  capability  for  acceptable  response 
time  to  user's  queries.  This  was  essentially  the  approach  taken  at  the 
Data  Processing  Service  Center  for  the  Pacific  (DPSCPAC)  at  San  Diego 
for  the  Aircraft  Power  Plant  Management  System  (APPMS)  data  base. 

At  the  Naval  Material  Command  Support  Activity  (NMCSA)  the  Aircraft 
Engine  Accounting  (AEA)  file  was  supported  by  IBM's  IMS  data  management 
system  and  had  an  existing  random  access  capability.  However,  as  the 
data  base  was  originally  structured  for  a purpose  other  than  NAVLIS, 
access  based  on  the  logistic  data  elements  of  interest  to  NAVLIS  was 
not  provided  by  IMS.  To  provide  that  access,  the  AEA  was  inverted  on 
the  data  values  of  interest  to  NAVLIS. 

While  creating  inverted  files  provided  random  access  not  available 
previously,  as  in  the  case  of  the  APPMS  file,  and  via  data  values  not 
accoiTimodated  previously,  as  with  the  AEA  file,  a significant  update 
problem  was  presented.  To  be  of  any  use,  the  inverted  files  had  to  stay 
in  synchronization  with  the  data  file.  This  required  that  the  inverted 
files  be  updated  whenever  a value  of  an  element  in  the  data  base  that 
had  been  inverted  changed.  The  actual  update  of  the  inverted  files  was 
little  problem,  as  the  files  and  the  update  programs  were  peculiar  to  NAVLIS 
and  had  no  impact  on  other  programs.  Identifying  when  values  were 
changing,  which  values  and  in  which  record,  was  entirely  different, 
especially  for  the  IMS  supported  data  base.  In  an  uncomplicated  update 
procedure,  where  all  changes  against  the  data  files  are  represented  by 
a tape  or  deck  of  transaction  records  (adds,  changes,  and  deletes)  that 


61 


are  batch  processed,  the  creation  of  a program  to  generate  transactions 
against  the  inverted  file  from  the  same  data  base  transactions  on  tape 
or  deck  is  an  efficient  solution  with  no  impact  on  the  user's  program. 

The  maintenance  procedures  for  an  on-line  data  base  supported  by  a data 
management  system,  however,  are  much  more  involved.  In  the  case  of  the 
AEA  file,  update  transactions  occurred  in  both  batch  and  on-line  modes 
and  the  maintenance  was  performed  by  IMS.  The  most  efficient  and  effective 
way  to  identify  these  transactions  was  to  develop  an  interface  between 
NAVLIS  and  IMS.  Briefly,  the  interface  intercepted  the  user  program  call 
to  IMS  and  saved  the  data  necessary  to  determine  what  action  was  occurring 
against  the  data  base.  The  resulting  file  of  activity  against  the  data 
base  was  later  processed  by  a NAVLIS  program  to  update  the  inverted  file 
for  the  AEA  data  base.  This  approach  had  the  advantages  of  minor  impact 
on  IMS  and  required  no  change  to  any  of  the  user's  programs.  A compre- 
hensive discussion  of  the  NAVLIS-IMS  interface  appears  in  Appendix  A. 

The  point  here  is  to  identify  the  difficulty  that  was  developing 
in  the  attempt  to  maintain  the  inverted  files  necessary  for  random  access 
current  with  the  latest  version  of  the  data  base  to  be  accessed,  without 
significant  modifications  to  the  applications  programs  that  used  that 
data  base.  As  the  structure  of  the  logistics  data  bases  and  the  programs 
that  maintain  those  data  bases  become  more  sophisticated,  the  interface 
becomes  more  complicated. 

Early  in  the  design  phase  consideration  was  given  to  much  more 
sophisticated  and  efficient  methods  of  providing  random  access  to  DMS 
supported  data  bases  by  using  the  indices  (directories,  inverted  lists, 
etc.)  used  by  the  DMS  itself  to  effect  random  access,  provided  the  DMS 
indices  included  the  logistics  element  relevant  to  a NAVLIS  user.  This 
approach  would  eliminate  the  inverted  file  storage  space  overhead  as  well 
as  the  problem  of  maintaining  the  inverted  file  (assuring  the  DMS  indices 
were  kept  current  with  data  base  changes). 

Another  alternative  that  would  have  eliminated  the  use  and  mainte- 
nance of  NAVLIS  inverted  files  was  to  perform  a translation  for  each  DMS 
supported  data  base  that  would  express  the  NAVLIS  retrieval  requirements 
in  a format  understandable  by  the  native  DMS.  The  DMS  would  perform  the 
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retrieval  func*’ions  using  its  own  indices  and  the  output  would  be  refor- 
matted to  be  compatible  with  responses  from  other  data  bases. 

Both  of  these  approaches  would  have  served  to  eliminate  the  need 
for  the  NAVLIS  inverted  files.  The  disadvantages,  however,  appeared  to 
far  outweigh  the  benefits.  The  software  development  required  to  interface 
directly  with  the  indices  maintained  by  a data  management  system  such  as 
IMS  is  considerable.  Once  developed,  the  stability  of  tiiat  software  is 
largely  affected  by  the  stability  of  the  associated  DMS'.  As  new  versions, 
enhancements,  and  modifications  to  the  DMS  are  incorporated,  the  probabil- 
ity of  corresponding  modifications  to  the  interfacing  software  is  high. 

The  alternative  of  translating  NAVLIS  requirements  into  DMS  statements 
limits  the  NAVLIS  capabilities  for  that  data  base  to  those  of  the  sup- 
porting DMS.  In  either  case,  the  interface  is  difficult  and  places  the 
retrieval  function  of  the  system  in  a position  of  dependency  upon  foreign 
software  packages. 

The  relative  ease  with  which  transactions  against  the  IMS  data  base 
could  be  captured  and  used  to  update  the  NAVLIS  inverted  files  obviated 
the  need  for  one  of  the  more  difficult  interfaces  above.  Additionally, 
the  incorporation  of  the  secondary  hit  resolution  capability,  allowing 
retrieval  on  noninverted  data  elements,  drastically  reduced  the  inverted 
file  storage  overhead. 

8.1.6  DATA  ACCESS  RESTRICTION  CONSIDERATIONS 

Handling  classified  data  and  data  considered  proprietary  by  its  user 
organization  was  an  early  NAVLIS  problem  and  had  yet  to  receive  adequate 
attention  when  the  project  was  terminated.  Since  the  Pilot  Model  was  to 
use  dial-up  lines  and  non-secure  facilities,  unclassified  files  were 
selected  for  use  and  the  problem  was  avoided.  It  was  well  recognized, 
however,  that  an  operational  NAVLIS  network  would  be  required  to  accommo- 
date classified  data  or  its  usefulness  to  logistics  managers  and  planners 
would  be  significantly  reduced.  Instructions  for  handling  classified  data 
are  explicit  concerning  requirements  for  system  components,  e.g.,  data 
transmission,  terminal  access,  etc.  One  of  the  difficulties  peculiar  to 
a NAVLIS-type  system,  due  to  the  multi-file  access  capability,  is  the 
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inadvertent  creation  of  classified  information.  The  ability  to  collect 
otherwise  remote  pieces  of  information  presents  the  possibility  of 
generating  classified  material  by  aggregation.  Only  when  the  aggregation 
could  be  pre-defined  could  system  safeguards  be  incorporated  to  recognize 
when  the  collection  was  being  compiled.  For  example,  when  various  types 
of  data  are  susceptable  to  classification  by  aggregation,  the  NAVLIS 
system  could  recognize  the  possible  generation  of  classified  data. 

The  File  Selection  Module  uses  the  contents  of  the  systems  data  files, 
identified  by  data  type,  to  determine  which  data  bases  are  candidates 
to  respond  to  the  user's  query.  It  is  at  this  point  in  the  processing 
that  the  system  could  detect  the  possible  generation  of  classified 
information  by  combining  certain  data  types.  However,  this  approach 
could  generate  many  false  alarms.  The  user  could  be  informed  of  the 
possibility  of  generating  classified  information  with  his  query,  but 
the  value  of  such  a warning  is  questionable.  It  would  do  nothing  to 
prevent  intentional  unauthorized  retrieval.  Another  option  might  be 
to  notify  a system  security  organization  which  could  determine  the 
classification  of  the  output  generated  prior  to  its  receipt  by  the  user 
and  also  determine  the  user's  authorization  for  access  to  that  data. 

The  question  of  handling  and  even  identifying  classified  data  in  a 
NAVLIS  system  needs  considerably  more  attention.  There  is,  however, 
another  level  of  security  of  concern  to  organizations  which  allow  their 
data  bases  to  become  part  of  a data  sharing  network.  The  issue  is  not 
one  of  sharing  classified  data,  but  of  releasing  "unsanitized"  data. 

In  many  cases,  information  generated  from  a data  base  is  reported  to 
higher  coirariand  levels  only  after  it  has  been  "approved"  at  lower  levels. 
Lower  and  middle  level  managers  are  concerned  about  the  exposure  of  upper 
management  to  raw  data.  Often  there  are  legitimate  reasons  for  this 
concern.  Frequently  data  values  need  some  manipulation  or  should  be 
considered  in  combination  with  other  data  elements  to  be  meaningful  and 
accurate.  The  total  "quantity-on-hand"  of  an  item  could  be  very  mis- 
leading without  consideration  of  the  status  of  the  individual  items. 

The  retrieval  of  this  type  of  accurate  but  incomplete  data  is  a legiti- 
mate concern. 


64 


As  with  the  classification  problem,  the  system  software  can  provide 
protection  against  incomplete  retrieval  only  to  the  extent  that  it  can  be 
defined.  When  data  elements  should  be  retrieved  together  to  be  complete, 
a user  requesting  only  part  of  the  data  can  be  advised  that  the  output 
may  be  misleading,  or  the  remainder  of  the  data  could  be  automatically 
retrieved  and  presented  to  the  user  as  an  addition  to  the  requested  output. 
A primary  difficulty  comes  with  identifying  the  data  combinations. 

Personnel  familiar  with  a single  data  base  may  be  able  to  determine  the 
meaningful  combinations  of  data  for  that  base,  but,  as  multiple  data 
bases  are  incorporated  into  the  network  and  the  user  can  retrieve  and 
combine  data  from  any  of  the  system  data  bases  simultaneously,  the 
difficulty  of  identifying  incomplete  data  combinations  is  increased 
significantly. 

Another  aspect  of  the  same  problem  concerns  data  that,  although 
unclassified,  is  for  limited  distribution.  In  determining  what  data 
are  to  be  retrieved  in  response  to  a query,  the  NAVLIS  system  processes 
with  successively  more  specific  levels  of  identification.  Facilities 
with  data  relevant  to  the  query  are  identified,  then  data  bases  resident 
at  that  facility,  records  within  the  data  bases,  data  elements  within 
the  records,  and  sub-elements  of  data  elements.  Restricted  access  can 
be  recognized  and  enforced  at  any  of  these  levels.  For  some  users, 
access  might  be  unequivocably  denied.  A dialogue  could  be  initiated 
with  other  users  to  determine  authori zatiohr-  Other  conditions 
might  require  notification  of  an  individual  responsible  for  granting 
or  denying  access  based  on  the  user  and  his  requirements.  The  NAVLIS 
Pilot  Model  included  an  elementary  provision  for  allowing  access  to 
certain  data  bases  only  through  a three-character  user  or  facility 
identification.  In  the  Pilot  Model  access  restriction  was  at  the  file 
level,  i.e.,  a user  was  either  permitted  or  denied  access  to  an  entire 
data  base.  It  might  be  desirable,  for  example,  to  permit  only  a subset 
of  the  system  users  to  retrieve  from  a certain  personnel  file.  Restric- 
tion at  a lower  level,  either  the  record  or  data  element  level,  would 
also  be  required  for  an  operational  system.  The  NAVLIS  system  design 
incorporates  two  modules  well-suited  for  providing  more  selective  data 
privacy. 


The  File  Selection  Module  (FSM)  currently  enables  the  system  soft- 
ware to  determine  which  data  bases  in  the  network  can  respond  to  a query 
by  comparing  the  data  elements  involved  in  the  query  with  the  data 
elements  contained  in  the  system  data  bases.  The  module  uses  a support 
file,  the  File  Content  Directory,  which  contains  the  identification  and 
location  of  each  data  base  in  the  network  associated  with  a list  of  the 
data  elements  in  that  data  base.  The  file-level  access  verification  is 
currently  performed  by  this  module,  and  the  FSM  is  the  logical  point  for 
enforcing  data  element  restriction.  The  user's  identification  could  be 
included  in  the  comparison  of  the  data  elements  in  the  query  with  those 
in  the  data  base  to  determine  whether  the  user  was  allowed  access  to 
those  data  elements  in  that  data  base.  The  File  Content  Directory 
could  be  expanded  to  indicate  not  only  the  data  element  content  of  each 
data  base,  but  also,  for  those  data  elements  with  limited  access,  the 
user's  who  were  permitted  to  retrieve  those  data  elements.  This  capabil- 
ity would  provide  for  allowing  a user  access  to  a personnel  file  for  all 
but  data  concerning,  for  example,  an  individual's  past  and  current  earn- 
ings. In  this  way  any  unauthorized  retrieval  attempts  can  be  detected 
very  early  in  the  processing  cycle  before  any  remote  site  transmission 
has  occurred  and  prior  to  opening  any  of  the  system  data  bases. 

It  would  be  also  useful  to  be  able  to  restrict  access  on  the  basis 
of  record  type  and  certain  data  values  rather  than  by  data  types.  This 
type  of  restriction  is  difficult  to  accommodate  without  accessing  the 
data  base,  but  can  be  effected  prior  to  making  the  data  available  to 
the  user.  The  ADS  Interface  Module  provides  the  logical  point  in  the 
processing  cycle  to  enforce  both  record  and  value  restrictions.  After 
retrieval  of  a record  from  the  data  base,  the  record  type  can  be  compared 
to  any  user  ID  restrictions  for  that  data  base  before  retrieving  data 
values  from  the  record.  When  no  restrictions  apply  or  when  the  user  is 
permitted  access  to  that  record  type,  processing  continues  normally. 

If  the  user  is  not  allowed  access  to  that  record  type,  a warning  may  be 
issued,  processing  may  be  terminated,  or  the  record  may  be  ignored  and 
the  next  hit  record  accessed  for  processing.  Summary  type  information 
might  be  available  to  a large  class  of  users,  but  access  to  detail  records 
would  be  limited. 


Restricting  access  on  the  basis  of  the  values  of  certain  data 
elements  could  also  be  incorporated  and  could  be  performed  by  the 
ADS  Interface  Module.  In  the  personnel  data  base  example,  a user 
may  be  allowed  access  to  records  for  all  personnel  except  those  with 
certain  job  classifications.  When  such  restrictions  are  indicated, 
the  ADS  Interface  Module  can  test  the  value  of  restricting  data  elements 
in  conjunction  with  the  user  ID  before  retrieving  the  requested  data 
elements.  Note  that  the  data  elements  requested  need  not  include  the 
data  element(s)  on  which  access  is  restricted  to  prevent  retrieval. 


8.2  RECOMMENDATIONS 

The  following  recommendations  are  presented  without 
explanation  of  the  area  to  which  each  recommendation  applies, 
acknowledging  that  a reader  needs  an  understanding  of  each  area 
to  fully  appreciate  the  potential  of  a given  recommendation. 

(a)  The  NAVLIS  Executive  and  Telecommunications  Subsystem 
should  be  examined  for  possible  utilization  in  other 
logistics  systems  such  as  WWMICS  and  NAICOHMIS. 

(b)  Consideration  should  be  given  to  utilizing  NAVLIS 
technology  to  network  the  Navy  Data  Processing 
Service  Centers. 

(c)  Consideration  should  be  given  to  implementing  the 
NAVLIS  Executive  and  Telecommunications  Subsystems 
at  DPSCLANT  to  serve  the  TYCOMS  in  the  Norfolk  area 
and  other  outside  DPSCLANT  users  through  on-line 
applications. 

(d)  Differences  in  oerception  of  NAVLIS  utility  between 
LANTFLT  and  PACFLT  should  be  oursued  to  determine 
whether  the  concept  does  indeed  have  a useful  role  in 
support  of  the  fleet. 

(e)  Attention  should  be  given  to  the  technology  develoned 
in  the  NAVLIS  project  as  it  relates  to  on-qoing  OMR 
sponsored  programs  at  the  university  level. 
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APPENDIX  A 

. \ 

j NAVLIS  EXECUTIVE  SUBSYSTEM  SOFTWARE  DOCUMENTATION 

j 

||  A.l  INTRODUCTION 

This  appendix  represents  the  software  documentation  for  those 
developments  that  are  unique  to  a NAVLIS-type  system.  As  mentioned 
in  the  body  of  the  final  report  to  which  this  is  appended,  the  data 
management  functions  were  absorbed  into  the  NAVLIS  software  from  an 
existing  DMS  (SHARP).  Additional  module  development  was  required 
for  the  functions  of  system  control,  file  selection,  hit  resolution, 
synonym  resolution,  and  interface  with  the  data  bases  against  which 
retrieval  would  be  effected.  These  functions  represent  (a)  the  dif- 
ferences between  NAVLIS  and  other  developments  in  data  retrieval,  and 
(b)  the  technical  accomplishments  necessary  to  demonstrate  system 
feasibility  and  to  implement  the  system  at  the  Pilot  Model  sites. 

This  appendix  describes  only  those  modules  unique  to  NAVLIS,  which 
comprise  the  Executive  Control  Subsystem.  Those  functions  typically 
associated  with  data  management  systems,  i.e.,  query  interpretation, 
report  generation,  etc.,  are  not  documented  herein.  The  format  is  as 
follows  for  each  module  described: 

* Title  and  acronym(s)  of  module 

* Purpose:  Statement  of  the  purpose(s)  of  the  module. 

• Inputs:  A description  of  the  inputs  to  the  module  and 

their  source. 

• Outputs : A description  of  the  outputs  from  the  module 

and  their  destination. 

• Record  Formats:  Detailed  record  layouts  for  input,  output, 

and  records  generated  for  internal  use. 

• Storage 

Requirements : Statement  indicating  the  size  of  the  module. 
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• Processing 

Description:  Narrative  statement  of  module  processing  coin- 

ciding with  the  program  flow  chart. 

• Program  Flowchart:  A graphic  statement  of  module  processing. 

Section  5.0  in  the  final  report  provides  a brief  description  of  the 
sequence  of  module  execution  that  will  assist  the  reader  in  putting  the 
descriptions  of  individual  modules  into  the  content  of  system  execution. 

Sections  A. 9 and  A. 10  are  modules  unique  to  the  requirement  to 
interface  with  IBM's  IMS  data  management  system  at  NMCSA.  These  modules 
represent  the  interface  necessary  to  monitor  and  capture  IMS  transactions 
against  the  data  base  for  use  in  updating  the  Inverted  Master  Files  for 
that  data  base. 


A. 2 TITLE:  EXECUTIVE  CONTROL  MODULE  (ECM) 

A. 2.1  PURPOSE:  To  control  processing  of  queries  and  report  definitions 

for  displaying  the  results  of  the  retrieval  to  the  user.  ECM  also  handles 
communications  and  error  recovery  during  these  processes. 

A. 2. 2 INPUTS 

The  main  inputs  to  ECM  are  the  Module  Communications  Region  (MCR) 
and  an  I/O  buffer  area  (NTS-BUFFER)  found  in  the  Linkage  Section  between 
the  NAVLIS  Telecommunications  Subsystem  (NTS)*  and  ECM.  This  section 
contains  the  indicators  and  data  from  NTS  necessary  for  accurate  flow  and 
processing.  The  Constraint  File  (CONSTR-FILE)  is  read  by  ECM  following 
creation  by  the  Query  Translator  Module  (QTM)  and  modification  by  the 
Screening  Module  (SCRM)  and  the  File  Selection  Module  (FSM).  CONSTR-FILE 
contains  the  translated  constraints  which  the  user  has  specified  in  his 
query  for  retrieval.  The  Edit  File  (EDIT-FILE)  contains  the  reformatted 
records  generated  by  the  Report  Generator  Module  (RGM)  for  displaying 
the  results  of  the  user's  query  in  the  desired  format. 


* The  NAVLIS  Telecommunications  Subsystem  (NTS)  is  documented  under 
separate  cover  by  NAVCOSSACT.  See  Reference  1. 
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A. 2. 3 OUTPUTS 


The  Linkage  Section  described  above  also  acts  as  an  output  area 
for  ECM  in  the  communication  between  ECM  and  NTS.  In  addition,  two  out- 


put  files  are  generated. 

The 

Scratch  File 

(SCRATCH-FILE)  is  a collect 

of  undeliverable  records 

kept  for  later  recovery.  The  Response  File 

(RSVP-FILE)  contains  the 

records  retrieved 

from  the  full  data  files  in 

response  to  the  user’s  query. 

A. 2. 4 RECORD  FORMATS: 

See  Figures  A1-A7 

Module  Communications  Region 

Data  Field 

Position 

Mcture 

Function  code 

1-2 

S99 

Error  code 

3-4 

S99 

Request  code 

5-6 

S99 

Line  advance 

7-8 

S99 

Return  code 

9-10 

S99 

Message  size 

11-12 

S99 

Type  code 

13 

X 

Terminal  ID 

14-15 

XX 

Precedence 

16 

X 

Station  serial  no. 

17-20 

9(4) 

Content  indicator 

21-24 

X(4) 

Classification 

25 

X 

Filler 

26 

X 

Time  of  day 

27-32 

9(6) 

Buffer  size 

33-34 

S99 

Module  name 

35-40 

X(6) 

Constraint  File  (Asterisk  Record) 

Data  Field 

Position 

Picture 

Asterisk 

1 

X 

Site  ID 

2-7 

X(6) 

File  ID 

8-10 

XXX 

Filler 

11-80 

X(70) 
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r 


Data  Field 

Position 

Picture 

Carriage  control 

1 

X 

Rest  of  information 

2-72 

X(71) 

Filler 

73-80 

X(8) 

Response  File 

Data  Field 

Position 

Picture 

Filler 

1-16 

X(16) 

Character  count 

17-18 

99 

Variable  data 

19-114 

X(96) 

Site  Status  Table 

Data  Field 

Position 

' 

Picture 

Status  field 

1 

X 

Si  te 

2-7 

X(6) 

occurs 

Query  ID 

8-10 

XXX 

, 5 
times 

Question  no. 

11-13 

999| occurs 

No.  of  hits 

14-18 

> 

A. 2. 5 STORAGE  REQUIREMENTS 

Program  (less  library  modules)  occupies 

24,000  bytes  on 

UNIVAC 

I i Series  70/45. 

I i 
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Fold  bacii  tt  dottsd  Im*. 


fold  lMd(  at  dotlod  lino. 


CARD  OR  RECORD  LAYOUT  - DOUBLE 


back  M dottad  tma. 


b«di  »t  don*d  lina 


CARD  OR  RECORD  LAYOUT  - DOUBLE 


A. 2. 6 PROCESSING  DESCRIPTION:  (Refer  to  ECM  Flowchart,  page  24) 


T 


t 

I 
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The  Executive  Control  Module  (ECM)  is  called  by  the  NAVLIS  Tele- 
communications Subsystem  (NTS)  and  calls  the  modules  which  comprise  the 
retrieval  subsystem.  Processing  in  ECM  is  dependent  on  three  indicators 
which  control  the  flow  of  operation.  These  indicators  are  the  NTS 
function  code  (MCRFNC),  the  ECM  return  code  (MCRRET),  and  a relocator 
switch  (RELOCATOR).  The  MCRFNC  switch  is  set  by  NTS  to  inform  ECM  of 
the  function  to  perform.  The  MCRRET  switch  is  set  by  ECM  to  indicate 
an  immediate  return  to  ECM  by  NTS  and  subsequent  transfer  to  that  part 
of  the  program  to  be  executed  next.  The  RELOCATOR  switch  is  an  internal 
variable  within  ECM  which  acts  as  a secondary  transfer  code  for  a partic- 
ular function  code. 

NTS  enters  ECM  with  the  Module  Communication  Region  (MCR)  and  the 
NTS-BUFFER.  These  variables  enables  NTS  and  ECM  to  communicate  during 
execution.  These  calling  parameters  are  displayed  upon  entry  for  debug- 
ging purposes. 

Before  checking  MCRFNC  to  determine  what  function  to  perform, 

ECM  must  first  check  the  message  indicator  (MESS-IND).  ECM  is  respon- 
sible for  carriage  return  and  line  advance  when  messages  are  displayed 
to  the  user.  MESS-IND  greater  than  zero  indicates  that  a message  has 
been  put  out  and  that  ECM  should  return  to  NTS  for  carriage  return  and 
the  proper  line  advance.  MESS-IND  = 1 indicates  a single  line  advance. 
MESS-IND  = 2 indicates  no  line  advance.  MESS-IND  = 0 indicates  the 
task  has  been  performed  or  does  not  need  to  be  performed,  which  leads 
to  the  GO  TO  ---  DEPENDING  ON  MCRFNC.  The  following  table  lists  the 
transfer  points  and  functions  indicated  by  the  various  codes: 


MCRFN^ 

PARAGRAPH  NAME 

FUNajW 

1 

INITIAL 

Initial ization 

2 

INITIAL 

Restart 

3 

NO-OP 

No  function  to  perform 

4 

IST-MID-BLK 

Intermediate  data  block 

5 

FINAL-BLK 

Final  data  block 

6 

IST-MID-UND 

Intermediate  undelivera 

7 

FINAL-UND 

Final  undeliverable 

8 

CONS-REQ 

Console  message  request 

9 

TIME 

Time  of  day 
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(Continued) 


MCRFNC 

10 

NO -DATA 

No  data  in  the  buffer 

11 

TERM-REQ 

Request  for  termination 

12 

LINE-REACT 

Line  reactivated 

13 

IMMEDIATE-RETURN 

Provide  next  data  block 

A function  code  of  0 is  an  error  condition  resulting  in  display  of  a 
message  to  the  user  and  eventual  termination  of  the  run. 

The  INITIAL  paragraph  sets  the  various  switches  and  indicators  to 
their  initial  value,  returning  to  NTS  with  "no  request".  The  RELOCATOR 
switch  is  set  to  11  (see  RELOCATOR  function  summary). 

NO-OP  is  executed  when  MCRFNC  = 3.  In  this  case,  control  has  been 
given  to  NTS  by  ECM  with  the  return  code  set.  NTS  has  returned  to  ECM 
with  no  function  to  perform.  Transfer  is  made  to  that  part  of  ECM  to  be 
executed  next  via  a 60  TO  — DEPENDING  ON  MCRRET.  Each  of  the  paragraphs 
will  be  explained  as  they  are  encountered  in  the  flow. 

IST-MID-BLK  is  the  paragraph  executed  when  there  is  a first  or 
intermediate  data  block  in  the  buffer  from  NTS.  If  this  intermediate 
block  contains  the  counter  record  from  a remote  site,  the  record  is 
stored  and  ECM  returns  to  NTS  for  the  next  data  block.  If  the  error 
code  is  set,  control  goes  to  the  error  routine.  If  ECM  receives  a 
function  code  of  4 during  the  log-in  procedure,  return  is  made  to  NTS 
with  a request  to  purge  the  current  data  block.  If  none  of  the  above 
are  true,  the  data  block  is  assumed  to  be  a response  record  from  a 
remote  site.  The  record  is  written  on  the  response  file  and  ECM  returns 
to  NTS  with  a request  for  the  next  data  block. 

FINAL-BLK  is  executed  when  the  buffer  contains  the  final  or  only 
data  block  of  a message.  This  is  the  most  common  function  code. 

A second  level  GO  TO — DEPENDING  ON  is  used  for  transfer  to  the  proper 
area  of  processing.  This  secondary  transfer  code  is  the  RELOCATOR  switch 
mentioned  earlier.  The  following  table  lists  the  transfer  points  and 
function  indicated  by  the  RELOCATOR  switch. 
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OCATOR 

PARAGRAPH  NAME 

FUNCTION 

1 

FAC-CK 

Val idate  facil ity  id 

2 

USER-CK 

Val idate  user  id 

3 

PASSWRD-CK 

Validate  password 

4 

TRANSLA 

Translate  query 

5 

HIT-SELECTION 

Disposition  of  hits 

6 

ANOTHER-QUERY 

Prepare  for  next  query 

7 

FOURTEENTH 

Query  option 

8 

OPTION 

Query,  repdef,  or  end  option 

9 

NEXT-PARA 

Hit  resolution 

10 

OPEN-UP 

Open  inverted  files 

11 

GET-FIRST 

Prepare  for  facility  id  entry 

12 

ANOTHER-QUERY 

Prepare  for  next  query 

13 

GET-FIRST 

Prepare  for  facility  id  entry 

14 

CALL-REPDEF 

Report  definition 

15 

OPT 

Query,  repdef,  or  end  option 

16 

CALL-FSM 

File  selection 

The  IST-MID-UND  paragraph  handles  the  first  or  intermediate  blocks 
vjhich  are  undeliverable.  If  the  last  program  executed  was  R6M  or  FSM, 
the  unde? iverable  data  block  in  the  buffer  is  purged.  MOD-IND=RGM 
indicates  a report  undeliverable  to  the  user.  MOD-IND=FSM  indicates  a 
constraint  file  undeliverable  to  the  remote  site.  Neither  of  these 
need  be  saved  because  they  may  be  obtained  elsewhere.  All  other 
undeliverable  data  blocks,  such  as  messages  to  the  user,  are  saved  on 
the  scratch  file  for  retransmission. 

FINAL-UND  writes  the  last  undel iverable  data  block  on  the  scratch 
file.  If  this  is  the  only  data  block,  the  scratch  file  is  first  opened, 
then  written  on  and  closed.  If  the  error  indicator  is  set,  control  is 
transferred  to  ERR-CK  for  proper  return  to  NTS. 

CONS-REQ  is  the  paragraph  executed  when  a console  request  has  been 
issued  by  NTS  indicating  there  is  something  to  be  entered  at  the  console. 
ECM  returns  to  NTS  with  a no-request  to  allow  the  function  to  be  performed, 
TIME  obtains  the  time  of  day  from  NTS  and  passes  it  to  the  user  via 
NTS.  Note  that  the  return  code  is  set  for  immediate  return  to  ECM  after 
the  message  is  given  to  the  user.  This  is  for  the  carriage  return  and 
1 ine  advance. 
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NO-DATA  indicates  there  is  no  data  in  the  buffer,  In  this  case, 
the  error  indicator  is  checked  and  control  is  transferred  to  the  error 
paragraph  for  proper  handling.  If  the  error  indicator  is  not  set,  the 
user  is  advised  that  unrecoverable  errors  have  occurred  and  the  run  is 
terminated. 

TERM-REQ  handles  a request  for  termination  by  NTS.  ECM  returns  to 
NTS  with  a request  code  of  9 after  performing  the  necessary  housekeeping 
functions. 

Control  is  passed  to  the  LINE-REACT  paragraph  when  a line  is  reopened 
after  being  down.  If  R6M  was  the  last  module  executed  before  the  line 
went  down,  the  EDIT-FILE  is  closed  and  reopened  for  display  to  the  user. 

If  the  last  module  executed  was  FSM,  the  CONSTR-FILE  is  reread  and  trans- 
mitted to  the  proper  site  for  retrieval.  If  neither  RDM  nor  FSM  was 
executed  last,  the  records  on  the  scratch  file  are  retransmitted  to  NTS 
for  continued  processing. 

The  IMMEDIATE-RETURN  paragraph  is  executed  whenever  ECM  requests  that 
NTS  return  to  ECM  immediately  after  completing  the  current  request. 
Transfer  is  made  to  that  part  of  ECM  to  be  executed  next  via  a GO  TO — 
DEPENDING  ON  MCRRET.  If  this  return  code  has  not  been  set,  the  user  is 
notified  and  the  run  is  terminated. 

When  a user  dials  into  the  NAVLIS  system,  NTS  calls  ECM  with  a func- 
tion code  of  1 indicating  initialization.  ECM  then  sets  the  various 
switches  and  returns  to  NTS  with  RELOCATOR  = 11.  The  user  then  logs  into 
the  system  by  entering  "NLIS".  NTS  passes  this  message  to  ECM  via  the 
NTS-BUFFER  with  a function  code  of  5 indicating  that  the  buffer  contains 
a final  or  only  data  block.  Since  the  RELOCATOR  switch  had  been  set  by 
ECM  before  the  last  return  to  NTS,  control  is  passed,  first  to  the 
FINAL-BLK  paragraph,  and  then  to  GET-FIRST  where  ECM  asks  the  user  to 
enter  his  facility  id.  The  RELOCATOR  switch  is  again  set  to  transfer 
control  to  FAC-CK  for  validation  of  the  facility  id.  The  user  is  given 
three  attempts  at  a valid  facility  id.  If  he  does  not  succeed,  he  is 
advised  to  get  help,  and  the  run  is  terminated.  Entry  and  validation 
of  the  user  id  and  password  is  similar.  For  security,  however,  the 
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password  is  blacked  out  before  entry  by  overwriting  the  entry  line  with 
a series  of  literals  which  completely  fills  each  character  matrix.  The 
RELOCATOR  switch  then  transfers  control  to  OPTION.  The  OPTION  paragraph 
marks  the  end  of  the  logon  stage.  The  user  is  given  the  choice  of  QUERY, 
REPDEF,  or  END. 

The  REPDEF  option  enables  the  user  to  define  report  formats  from 
the  terminal.  ECM  calls  the  REPDEF  module  for  each  report  line  entered 
by  the  user.  The  calling  parameters  indicate  whether  ECM  should  return 
to  NTS  for  the  next  line  from  the  user  (MCRREQ  = 2),  put  out  an  error 
message,  or  end  the  procedure. 

The  END  option  simply  terminates  the  run  through  a request  code  of 
7.  NTS  then  completes  its  housekeeping  and  disconnects  the  line. 

The  QUERY  option  permits  the  user  to  interrogate  the  desired  data 
files  and  receive  the  results  at  the  terminal.  The  first  phase  of  this 
interrogation  is  the  Query  Translator  Module  which  translates  the 
English-like  query  entered  by  the  user  to  a form  which  can  be  understood 
by  the  retrieval  system.  ECM  calls  QTM  for  each  line  of  input.  As  in 
REPDEF,  the  calling  parameters  indicate  whether  ECM  should  return  to 
NTS  for  the  next  line  from  the  user,  put  out  an  error  message,  or  end 
the  procedure. 

When  the  user's  query  has  been  translated,  the  user  is  advised  of 

its  acceptance.  The  return  code  is  set  for  an  immediate  return  (MCRRET  = 

12)  and  ECM  returns  to  NTS.  Note  that  the  return  code  is  set  for  transfer 
in  this  case  rather  than  the  RELOCATOR  switch.  This  is  because  no  response 
is  required  from  the  user  before  returning  to  ECM.  Most  returns  prior 
to  this  required  user  input  which  was  then  validated  or  processed  accord- 
ingly. Immediate  return  to  ECM  after  a message  has  been  displayed  does 
not  permit  or  depend  on  this  input.  Control  is  transferred  to  that 
paragraph  referenced  by  the  return  code.  After  query  acceptance,  control 
passes  to  TWELFTH  in  which  the  Screening  Module  is  called.  This  program 
screens  the  output  of  QTM  for  report  validation,  etc. 

The  File  Selection  Module  is  the  next  program  executed  in  the 
retrieval  system.  The  user  is  asked  if  he  would  like  to  enter  file  para- 
meters to  limit  the  files  accessed.  If  he  responds  with  "yes",  he  is 
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directed  to  enter  his  parameters  in  a prescribed  format.  The  module 
communicates  with  the  user  through  the  use  of  ERROR-IND  and  INDICAT. 

Each  value  of  these  calling  parameters  indicates  a different  level  of 
response,  enabling  FSM  to  put  out  the  proper  message  to  the  user  and 
process  his  response  correctly. 

When  file  selection  is  complete,  all  remote  site  constraint  records 
are  transmitted  to  the  appropriate  site  for  retrieval.  Each  site  is 
identified  on  the  file  with  an  asterisk  record.  When  one  of  those 
records  is  encountered,  the  next  record  is  read.  If  this  next  record 
is  not  an  asterisk  record,  the  previous  record  is  transmitted  to  the 
proper  site.  This  process  is  continued  until  the  next  asterisk  record 
is  encountered.  Currently,  the  second  asterisk  record  signals  central 
site  processing  since  we  are  operating  with  only  two  sites.  During  the 
transmission  process,  control  fluctuates  between  PROCESS-FSM-FILE  and 
FIFTH. 

ERROR-PARA,  which  was  referenced  earlier,  puts  out  the  error 
messages  from  the  various  modules  to  the  user.  The  messages  are  passed 
to  ECM  via  the  calling  parameter,  ERREA.  ECM  then  passes  the  message 
to  NTS  line  by  line  in  NTS-BUFFER.  NTS  displays  each  line  to  the  user 
and  returns  to  ECM  for  the  next  line,  and  so  on.  When  all  lines  of  the 
message  have  been  put  out,  ECM  checks  the  various  switches  fo’"  transfer 
to  the  proper  area  of  processing. 

When  all  the  appropriate  constraint  records  have  been  transmitted 
to  the  remote  site,  the  constraint  records  for  the  central  site  are 
processed.  This  is  the  RCM  function  of  ECM.  The  processing  performed 
at  the  remote  site  is  duplicated  for  the  central  site  records.  OPEN-UP 
begins  this  procedure.  The  central  site  file  to  be  searched  is  identi- 
fied. Synonym  resolution  is  then  performed.  If  no  errors  are  encountered 
by  the  Synonym  Resolution  Module,  the  Primary  Hit  Resolution  Module  is 
called  to  select  hit  candidates  for  the  user's  query  from  the  specified 
inverted  file.  There  are  several  error  conditions  out  of  PHRM,  ERROR- 
IND  = 0 indicates  there  were  no  errors  and  primary  hit  resolution  is  com- 
plete. ERROR-IND  ■ 1 tells  ECM  that  PHRM  wishes  to  display  a message  to 
the  user  and  receive  control  again.  ERROR-IND  = 9 implies  that  there  were 
no  hits  for  any  question  at  the  central  site. 
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Successful  completion  of  primary  hit  resolution  results  in  a call 
to  the  ADS  module  associated  with  the  current  inverted  file.  This 
module  retrieves  the  requested  data  from  the  corresponding  direct  files 
and  returns  the  records  one  by  one  to  ECM  via  the  NTS-BUFFER.  ECM 
writes  these  records  on  the  response  file  as  they  are  received.  When 
ADS  returns  to  ECM  for  the  last  time,  the  NTS-BUFFER  contains  spaces, 
and  the  calling  parameter,  SITE-TABLE,  contains  a counter  record  which 
has  the  number  of  hits  for  each  question  from  the  current  file.  The 
hits  are  then  accumulated  for  the  central  site.  If  no  more  files  are 
to  be  processed  at  this  site  (ENDED  =1),  the  SITE-STATUS-TABLE  is 
updated  by  transferring  the  accumulated  hits  and  moving  an  asterisk 
to  the  status  field  to  indicate  completed  processing.  If  more  files 
are  to  be  processed,  control  is  transferred  to  OPEN-UP  for  file 
identification,  etc. 

UPDATE-SST  checks  the  status  field  for  each  site.  An  asterisk 
in  this  field  indicates  completed  processing.  If  all  sites  have 
returned  their  records,  control  is  transferred  to  ADVISER  for  dis- 
position by  the  user.  If  the  remote  site  has  not  yet  completed 
processing,  ECM  returns  to  NTS  to  wait  for  it. 

When  NTS  returns  to  ECM  with  the  response  records  from  the  remote 
site,  the  function  code  = 4 indicating  a first  or  intermediate  data 
block.  The  records  are  written  on  the  response  file  as  they  are 
returned.  The  counter  record  for  the  remote  site  is  passed  with 
a function  code  of  4.  ECM  stores  the  counter  record  and  returns  to 
NTS  for  the  final  data  block.  The  return  code  is  set  to  6 for  return 
to  SIXTH.  MCRFNC  = 5 and  MCRMSZ  = 0 indicate  that  the  counter 
record  was  stored  from  the  previous  data  block.  The  stored  record 
is  then  moved  to  NTS-BUF  to  be  handled  as  if  the  counter  record  had 
been  passed  in  the  NTS-BUF  with  a function  code  of  5,  which  is  another 
possibility.  The  SITE-STATUS-TABLE  is  then  updated  for  the  remote 
site. 

ADVISER  computes  the  number  of  hits  for  each  question  at  all 
sites.  If  none  of  the  user's  questions  have  hits,  the  user  is  notified 
and  given  the  option  of  submitting  another  query.  If  he  wishes  to 


do  so,  he  is  asked  to  input  his  query  commands  and  control  is  trans- 
ferred to  TRANSLA  via  the  RELOCATOR  switch,  If  the  user  does  not 
want  to  submit  another  query  at  this  point,  the  run  is  terminated. 

If  at  least  one  of  the  user's  questions  has  hits,  he  is  advised  of 
the  number  of  hits  and  given  the  option  of  deleting  or  printing  the 
results  of  each  question.  Those  questions  to  be  deleted  are  flagged 
in  the  DELETER  table.  If  all  questions  are  to  be  deleted,  control  is 
transferred  to  FOURTEENTH,  where  the  user  is  asked  if  he  wants  to 
submit  another  query.  If  the  results  of  one  or  more  questions  are  to 
be  printed,  the  Sort  Module  is  called.  This  module  sorts  the  data, 
eliminates  deleted  questions,  and  reformats  for  the  Report  Generation 
Module  which  is  called  next. 

RGM  develops  the  report  in  the  format  specified  in  the  user's 
query  and  writes  the  result  on  EDIT-FILE.  ECM  then  reads  EDIT-FILE, 
converts  the  carriage  control  to  NTS  standards,  and  displays  the 
report  to  the  user  line  by  line.  Lines  with  all  spaces  require  only 
a carriage  return.  Those  with  a carriage  control  of  space  require 
no  advance  (MCRADV  = 0).  Those  with  a carriage  control  of  zero 
require  a one  line  advance  (MCRADV  = -1  implies  write  after  advancing 
one  line).  Those  with  a carriage  return  of  1 require  a page  advance 
(MCRADV  = -5).  When  the  entire  report  has  been  printed,  the  user  is 
given  the  option  of  submitting  another  query.  Processing  then 
continues  as  described. 
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A. 2. 7 ECM/RCM  CONSOLIDATION 

The  Remote  Control  Module  (RCM)  directs  the  processing  of  the 
retrieval  modules  at  the  remote  site.  In  addition,  it  handles  com- 
munications and  error  recovery.  It  is  essentially  a subset  of  ECM, 
performing  synonym  resolution  through  hit  selection  at  the  remote  site. 
The  two  modules  have  therefore  been  combined  into  one  for  easier 
maintenance  and  control.  There  were  differences  in  remote  site  process- 
ing which  were  incorporated  in  the  combined  version.  These  are  noted 
below.  See  the  flow  chart  for  more  detail. 

A master  version  was  developed  containing  UNIVAC  and  IBM  code, 
identified  by  *U  or  *I  in  columns  seven  and  eight.  When  a new  load 
module  is  to  be  made  for  the  IBM  machine,  the  master  version  is  first 
copied  to  another  name.  All  coding  beginning  with  *U  is  then  edited 
out  under  Time  Sharing  Options  (TSO).  The  remainder  is  then  compiled 
to  create  a new  load  module.  Note  that  the  master  version  is  not 
changed  by  this  procedure. 

An  entry  point  was  added  to  the  new  ECMRCM  for  RCM.  This 
required  an  additional  parameter,  WKACPCB.  The  ADS  Interface  Module 
cannot  access  the  IMS  files  directly  due  to  certain  IBM  restrictions. 

NTS  must,  therefore,  access  the  files,  pass  the  results  through 
WKACPCB  to  RCM  which,  in  turn,  passes  it  to  the  AOS  Interface  Module. 

All  module  calls  were  modified  for  the  RCM  function  of  ECMRCM 
to  accommodate  IBM  requirements  of  double  quotes  arount  the  module 
name.  The  quotes  do  not  appear  on  the  enclosed  listing  because  the 
module  was  compiled  with  the  quote  option. 

The  remainder  of  the  differences  which  were  incorporated  in 
the  combined  version  of  ECM  and  RCM  are  listed  by  function  code  in 
the  chart  below.  Note  that  some  of  the  functions  which  were  performed 
by  RCM  are  handled  elsewhere  by  ECMRCM. 


88 


ECM/RCM  Differences 


MCRFNC  £C_M_ RCM 


1/2 

Sets  RELOCATOR  = 1 1 to  control 
subsequent  prompting  messages 

Checks  COiiSTR-FILE  and  SCRATCH- 
FILE  and  closes  them  if  they're 
open.  Clears  the  BREAK-DO'.'.'H 
array  where  hit  counts  are 
accumulated . 

3 

Control  routed  on  MCRRET 

Same 

4 

Checks  for  counter  record  and  stores 
it  if  found. 

Passes  control  to  error  paragraph 
if  error  code  is  set. 

Purges  current  message  if  in  log- 
in procedure. 

Opens  RSVP-FILE  in  output  mode  ' 

if  it  is  closed. 

'.■•’rites  record  to  RSVP-FILE 

Clears  BREAK-DOWN  array  if  its 
status  is  "in  use". 

Opens  CONSTR-FILE  in  output 
mode  if  it  is  closed. 

Writes  record  to  CONSTR-FILE. 

5 

Routes  control  on  STORE-ERR,  RSVP- 
OPED,  MCRERR,  or  FA^'-ID  if  set,  but 
normally  routes  control  on  RELOCATOR 
(if  0 RELOCATOR  17)  else  on 
MCRRET  (if  0 MCRRET  30)  else 
generates  an  error  message. 

Opens  CO.NSTR-FILE  if  not  open, 
writes  current  block  to  CONSTR- 
FILE  (if  block  f spaces),  and 
closes  CONSTR-FILE. 

Hard  coded  to  pass  control  to 
synonym  resolution  logic. 

6 

If  KOD-IND  = "FSM"  or  "ROM",  purges 
the  data 

Else  opens  SCRATCH-FILE  in  output 
mode  if  it  is  closed. 

Sets  AT-LEAST-ONE  = 1 
Writes  record  to  SCRATCH-FILE 

Same  but  not  as  an  else  cc  ? 
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MCRFNC 

ECM 

RCM 

7 

Clears  RELOCATOR  = 0. 

If  MCRMSZ  > 0,  opens  SCRATCH-FILE 
if  it  is  closed  and  writes  record. 
Closes  SCRATCH-FILE  if  open. 

If  MCRERR  > 0,  goes  to  ERR-CK. 

Same 

Moves  MESS21  to  NTS-BUF 

8 

Return 

Return 

i 

9 

Moves  MCRTOD  to  TIMER  array  and 
TIMER  to  NTS-BUF 
Sets  REQ  = 5 and  MCRRET  = 20 
for  subsequent  entry. 

Same 

! 

i 

1 

10 

Clears  RELOCATOR  = 0 
If  MCRERR  > 0,  goes  to  ERR-CK, 
else  goes  to  INSERTED-PARA 

Same(Minor  differences  in 
ERR-CK  and  INSERTED-PARA) 

MCRREQ  = 9;  MCRRET  = 0 
Closes  CONSTR-FILE  and/or 
SCRATCH-FILE  if  open. 

Sets  BREAK-DOWN  switch  to 
ensure  array  gets  cleared 
before  next  use. 


Routing  controlled  by  MCRRET 

MCRRET  = 7=>  retrieve  next 

record  from  SCRATCH-FILE  ! 

MCRRET  = 2=>call  ADSFACE  for^ 

1 

next  record. 


:ers  for 
rALID  MCRFNC 


SET  UP  PARAMETERS 
FOR  UNRECOVERABLE! 
ERRORS  MESSAGE 


MOVE  0 TO 
Validator 


FIND-SITE 


EIGHTEENTH 


ERROR'PARA/EIGHTH/NINTH 


CLOSE  CONSTR- 
FILE.  MOVE  0 
TO  CONSTR- 


CONT-TENTH  Erro-TENTH 


ENTER  LINKAGE 


CONTINUE-IT 


I MOVE  ZEROS  T( 
' EACH-SITE 


PROCESS-KCM-FILE 


END-OF-VAL/END-DL-VAL/END-DC-VAL 


ENTER  LINKAGE 


A. 3 TITLE:  Screening  Module  (SCRM) 


A. 3.1  PURPOSE 

The  Screening  Module  (SCRM)  makes  modifications,  needed  by  other 
modules,  to  the  Query  Constraint  File  (QCF)  which  was  output  by  the 
Query  Translator  Module  (QTM).  These  modifications  may  involve  refor- 
matting, adding,  and/or  deleting  records.  Changes  are  made  in  SCRM 
because  at  this  point  the  QCF  has  not  been  expanded  by  the  File  Selection 
Module  (FSM),  and  therefore  duplication  of  effort  will  not  result. 

A. 3. 2 INPUTS 

1.  IN-CONSTRAINT  - Query  Constraint  File  (QCF)  as  it  was  generated 
by  QTM.  File  contains  80-character  fixed  length  records. 

2.  REPT-DEFN  - Report  Definition  (REPDEF)  File  output  by  the  Report 
Definition  Module  (RDM).  The  REPDEF  File  is  an  indexed  sequential 
file  with  the  facility  ID  and  the  report  ID  as  its  key.  Each  record 
is  3110  characters  fixed  length. 


Data  Field 

Position 

Picture 

Value 

1. 

Delete  Code 

1 

X(l) 

Space  or  High 

2. 

Char.  Count 

2-5 

9(4) 

110-3110 

3. 

Filler 

6-11 

X(6) 

Asterisks 

4. 

RDF-ID 

a.  DB-NAME 

12-21 

x(io) 

Alphan. 

b.  Filler 

22-27 

X(6) 

"Report" 

c.  RPT-ID 

28-30 

X(3) 

Alphan. 

5. 

Data  Base  Type 

31-40 

x(io) 

Alphan. 

6. 

Master  Heading 

41-110 

X(60) 

A1 phan. 

7. 

Report  Type 

111 

x(i) 

"C"  or  Space 

8. 

LIRCS/PAGE 

112-114 

9(3) 

00-60 

9. 

Page  Width 

115-117 

9(3) 

60 

10. 

RDF  Block  occurs  100  times 

a.  LIRC 

X(4) 

X(4)  Numeric 

b.  RDF  INFO-1 

X(17) 

X(17)  Alphan. 

c.  Comp.  Code 

X(l) 

X(l)  "A"...."l 

d.  RDF  INFO-2 

X(8) 

X(8)  Alphan. 
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A. 3. 3 OUTPUT 

OUT-CONSTRAINT  - QCF  as  revised  by  SCRM.  Records  are  still  80 
characters  fixed  length.  Records  may  have  been  changed,  added,  and/or 
deleted  as  specified  in  Section  A. 3. 6 (PROCESSING  DESCRIPTION).  Record 
type  is  indicated  in  parentheses  following  record  name. 


Site/File  ID  Record 

(*) 

Data  Field 

Position 

Picture 

Value 

1. 

Asterisk 

1 

X(l) 

11*11 

2. 

Site  ID 

2-7 

X(6) 

Alphan. 

3. 

File  ID 

8-10 

X(3) 

A1 phan . 

4. 

File  Type 

11 

x(i) 

"R"  or  " 

Merge  Record  (A) 

Data  Field 

Position 

Picture 

Value 

1. 

Query  ID 

1-3 

X{3) 

Alphan. 

2. 

Question  No. 

4-6 

X(3) 

Numeric 

3. 

Filler 

7-8 

X(2) 

Spaces 

4. 

Type  Code 

9 

x(i) 

"A" 

5. 

Set  No. 

10-11 

X(2) 

00  or  01 

6. 

Filler 

12-80 

X(69) 

Spaces 

Report  Selection  Record  (B) 

Data  Field 

Position 

Picture 

Value 

1. 

Query  ID 

1-3 

X(3) 

Alphan. 

2. 

Question  No. 

4-6 

X(3) 

Numeric 

3. 

Filler 

7-8 

X(2) 

Spaces 

4. 

Type  Code 

9 

X(l) 

"B" 

5. 

Set  No. 

10-11 

X(2) 

Numeric 

6. 

Filler 

12 

x(i) 

Space 

7. 

Literal 

13-18 

X(6) 

"Report" 

8. 

Filler 

19 

X(l) 

Space 

9. 

Facility  ID 

20-25 

X(6) 

Alphan. 
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10. 

Filler 

26 

X(l) 

Space 

1 

11. 

Report  ID 

27-29 

X(3) 

Alphan. 

12. 

Filler 

30-80 

X(51) 

Spaces 

D.  Computation  Record 

(C) 

Data  Field 

Position 

Picture 

Value 

1 . 

Query  ID 

1-3 

X(3) 

Alphan. 

2. 

Question  No. 

4-6 

X(3) 

Numeric 

3. 

Filler 

7 

X(l) 

Space 

4. 

Control  In 

8 

X(l) 

"K","N",  or  "P" 

5. 

Type  Code 

9 

X(l) 

"C" 

6. 

Set  No. 

10-11 

X(2) 

Numeric 

1 

i 

7. 

Comp.  Code 

12 

X(l) 

"A". . ."H" 

1 

8. 

LIRC-1 

13-16 

X(4) 

Numeric 

9. 

Filler 

17 

X(l) 

Space 

r 

10. 

Acronym-1 

18-27 

X(10) 

Alphan. 

1 

1 

11. 

Filler 

28 

X(l) 

Space 

12. 

Form(Type)-l 

29 

X(l) 

I ,R,N,A,L,  or  Space 

13. 

Decimal -1 

30 

X(l) 

Numeric  or  Space 

14. 

Filler 

31-32 

X(2) 

Spaces 

i 

4 

* 15. 

LIRC-2 

33-36 

X(4) 

Numeric 

i 

i 

16. 

Filler 

37 

X(l) 

Space 

* 17. 

Acronym-2 

38-47 

x(io) 

Alphan. 

i 

18. 

Filler 

48 

X(l) 

Space 

t 

I 

j 

* 19. 

Form(Type)-2 

49 

x(i) 

I,R,N,A,L,  or  Space 

* 20. 

Decimal -2 

50 

x(i) 

Numeric  or  Space 

i 

i 

1 

? 

21 . 

Filler 

51-80 

X(30) 

Spaces 

* Only  for  certain  Comp.  Codes 

i 

E.  Sort 

Record  (D) 

Data  £iel d 

Posi tion 

Pj^ture^ 

Value 

■' 

1. 

Query  ID 

1-3 

X(3) 

Alphan. 

2. 

Question  No. 

4-6 

X(3) 

Numeric 

. i 

114 

hi 

, 

3. 

Filler 

7-8 

X(2) 

Spaces 

4. 

Type  Code 

9 

X(l) 

"D" 

5. 

Set  No. 

10-11 

X(2) 

Numeric 

6. 

High/Low 

12 

x(i) 

H,L,  or  Space 

7. 

LIRC 

13-16 

X(4) 

Numeric 

8. 

Pref ix/Partial 

17-26 

x(io) 

^(NUM)  or  *NUM  (NUM) 

9. 

Char.  Count 

27-30 

9(4) 

Numeric 

10. 

Filler 

31-80 

X(50) 

Spaces 

^NUM 

= 000  - 999 

Variable  Heading  Record  (H) 

Data  Field 

Position 

Picture 

Value 

1 . 

Query  ID 

1-3 

X(3) 

Alphan. 

2. 

Question  No. 

4-6 

X(3) 

Numeric 

3. 

Filler 

7-8 

X(2) 

Spaces 

4. 

Type  Code 

9 

X(l) 

"H" 

5. 

Set  No. 

10-11 

X(2) 

Numeric 

6. 

Filler 

12 

X(l) 

Space 

7. 

Variable  Heading 

13-72 

X(60) 

Alphan. 

8. 

Filler 

73-80 

X{8) 

Spaces 

Selection  Record  (J) 

Data  Field 

Position 

Picture 

Value 

1 . 

Query  ID 

1-3 

X(3) 

A1 phan . 

2. 

Question  No. 

4-6 

X(3) 

Numeric 

3. 

Filler 

7-8 

X(2) 

Spaces 

4. 

Type  Code 

9 

X(l) 

"J" 

5. 

Set  No. 

10-11 

X(2) 

Numeric 

6. 

Filler 

12 

X(l) 

Space 

7. 

LIRC 

13-16 

X(4) 

Numeric 

8. 

Filler 

17-26 

X(10) 

Spaces 

9. 

Parallel  Ind. 

27 

X(l) 

"P"  or  Space 

10. 

Filler 

28-80 

X(53) 

Spaces 
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H.  Constraint  Record  (L-Z) 


1-  ; 


Data  Field  Position 

1 . Query  ID  1-3 

2.  Question  No.  4-6 

3.  OP  Code  7-8 

4.  Type  Code  9 

5.  Set  No.  10-11 

* 6.  Mod(L/R)  ,12 

* 7.  Link  13 

* 8.  Role  14 

9.  Search  Type  15 

10.  LIRC  16-19 

*11.  No.  of  Links  20-21 

* 12.  No.  of  Sets  22-24 

13.  Inversion  Indie.  25-26 

14.  Parallel  LIRC 

Indie.  27 

15.  Efficiency  Code  28 

16.  Search  Value(s) 

a.  Non-Ranging 

Search  29-78 

b.  Ranging  Search 

1)  Value-1  29-53 

2)  Value-2  54-78 

17.  Filler  79-80 


Picture 

Value 

X(3) 

Alphan. 

X(3) 

Numeric 

X(2) 

"BN","EQ’’,"GE", 
"GR' ,"LE","LS", 
or  "NE" 

x(i) 

"L" 

X(2) 

Numeric 

X(l) 

Alphan. 

X(l) 

A1 phan . 

X(l) 

Alphan. 

X(l) 

"W","X","P",  or  " 

X(4) 

Numeric 

9(2) 

Numeric 

9(3) 

Numeric 

X(2) 

Numeric  or  Spaces 

x(i) 

"P"  or  Space 

x(i) 

"X"  or  Space 

X(50) 

A1 phan . 

X(25) 

Alphan. 

X(25) 

Alphan. 

X(2) 

Spaces 

i 


II 


* Currently  not  used  in  NAVLIS  System,  treat  as  filler. 
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I.  Parallel  LIRC  Record  (9) 


Data  Field 

Position 

Picture 

Value 

1 , 

Query  ID 

1-3 

X(3) 

Alphan. 

2, 

Question 

No. 

4-6 

X(3) 

Numeric 

3. 

Filler 

7-8 

X(2) 

Spaces 

4, 

Type  Code 

9 

X(l) 

iign 

5, 

Set  No. 

10-11 

X(2) 

Numeric 

6. 

Filler 

12-15 

X(4) 

Spaces 

7, 

LIRC 

16-19 

X(4) 

Numeric 

8, 

Filler 

20 

X(l) 

Space 

9, 

Paral lei 

LIRC 

#1 

21-24 

X(4) 

Numeric 

or 

Spaces 

10, 

Filler 

25 

X(l) 

Space 

11 , 

Parallel 

LIRC 

#2 

26-29 

X{4) 

Numeric 

or 

Spaces 

12. 

Filler 

30 

X(l) 

Space 

13. 

Parallel 

LIRC 

#3 

31-34 

X(4) 

Numeric 

or 

Spaces 

14. 

Filler 

35 

X(l) 

Space 

15. 

Parallel 

LIRC 

#4 

36-39 

X(4) 

Numeric 

or 

Spaces 

16. 

Filler 

40 

X(l) 

Space 

17. 

Parallel 

LIRC 

#5 

41-44 

X(4) 

Numeric 

or 

Spaces 

18. 

Filler 

45 

X(l) 

Space 

19. 

Parallel 

LIRC 

#6 

46-49 

X(4) 

Numeric 

or 

Spaces 

20. 

Filler 

50 

X(l) 

Space 

21. 

Paral lei 

LIRC 

#7 

51-54 

X(4) 

Numeric 

or 

Spaces 

22. 

Filler 

55 

X(l) 

Space 

23. 

Parallel 

LIRC 

m 

56-59 

X(4) 

Numeric 

or 

Spaces 

24. 

Filler 

60 

X(l) 

Space 

25. 

Parallel 

LIRC 

#9 

61-64 

X(4) 

Numeric 

or 

Spaces 

26. 

Filler 

65 

x(i) 

Space 

27. 

Parallel 

LIRC 

#10 

66-69 

x(ii) 

Spaces 

A. 3,4  RECORD  FORMATS  - See  Figures  A1-A5  and  A8. 

A. 3. 5 STORAGE  REQUIREMENTS: 

Program  (less  library  modules)  occupies  27,000  bytes  on  UNIVAC 
Series  70/45, 
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A. 3. 6 PROCESSING  DESCRIPTION  (Refer  to  SCRM  Flowchart,  page  55) 

A. 3. 6.1  GENERAL  DESCRIPTION 

SCRM  creates  the  new  QCF  by  reading  and  storing  the  old  QCF 
records  and  processing  the  different  record  types  for  each  question. 
Whenever  all  the  constraints  for  a question  have  been  stored,  SCRM 
will  do  some  final  checking  on  parallelism  and  on  adding  J-type  Logistic 
Information  Requirements  Codes  (LIRC).  Then  all  the  stored  records  for 
the  question  will  be  written  to  the  new  QCF.  The  above  processing 
continues  for  all  questions  until  an  end-of-file  is  encountered  on  QCF. 

A. 3. 6. 2 LZ  ROUTINE 

For  all  L through  Z constraints,  SCRM  first  determines  whether 
the  search  type  is  prefix  (X).  If  it  is  prefix  and  the  operation  code 
(op  code)  is  NE,  then  all  spaces  of  the  search  value  will  be  replaced 
by  asterisks  (*).  If,  however,  the  op  code  is  not  NE,  then  SCRM  changes 
the  search  type  to  whole  (w)  and  replaces  the  spaces  in  the  search  value(s) 
with  low-values  or  high-values,  whichever  is  appropriate.  For  example, 
a greater  than  (GR)  search  on  value  ABC  (spaces)  will  become  a GR  search 
on  value  ABC  (low-values).  If,  however,  the  op  code  is  EQ,  SCRM  will 
change  it  to  BE  and  move  the  value  of  the  first  search  value  into  the 
second  search  value  field.  Then,  all  the  spaces  in  the  first  value  will 
be  changed  to  low-values  and  those  of  the  second  value  to  high-values. 

After  the  prefix  checking  for  a record  is  done,  the  efficiency  indicator 
is  checked. 

If  the  efficiency  indicator  is  on  (X),  then  the  op  code  is 
checked.  If  it  is  a range  operator  (BE,BH,BL,  or  BN),  then  an  efficiency 
search  cannot  be  performed  on  the  constraint  so  the  efficiency  indicator 
is  reset  to  space.  For  all  other  op  codes,  the  original  op  code  will  be 
replaced  by  its  complement,  (e.g.  NE  becomes  EQ,  GR  becomes  LE,  etc.). 

Then  the  L through  Z record  is  stored  in  the  LZ  table. 
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A. 3. 6. 3 CJB  ROUTINE  (also  includes  ADH  processing) 

For  all  C or  J records,  SCRM  stores  the  record  in  the  CJ  table. 

If  it  is  a J record,  then  the  J flag  is  set  to  1.  For  a B record,  SCRM 
sets  the  B flag  to  1,  stores  the  B record,  and  creates  the  REPOEF  key 
using  the  facility  10  and  the  report  ID.  SCRM  stores  the  remaining  records 
(A,D,  or  H)  in  the  ADH  table. 

A. 3. 6. 4 PARALLEL  PROCESSING 

When  a type  9 record  is  encountered  while  reading  the  QCF,  SCRM 
determines  whether  any  parallelism  has  already  been  found.  If  not,  SCRM 
checks  the  newest  9 record  for  parallelism. 

Parallelism  exits  when  two  or  more  L-Z  LIRCs  are  parallel  to 
each  other.  (The  two  LIRCs  may  be  identical.)  Each  L-Z  LIRC  which  is 
parallel  to  other  LIRCs  causes  a type  9 record  to  be  created  on  the  QCF 
in  QTM.  The  9 record  contains,  first,  the  LIRC  which  was  on  the  L-Z 
constraint  (the  QCF  LIRC)  and  then  all  the  LIRCs  parallel  to  it  in  numer- 
ical order.  Parallelism  is  such  that  if  LIRC  A ;s  parallel  to  LIRC  B, 
then  LIRC  B is  also  parallel  to  LIRC  A.  Furthermore,  if  LIRC  C is 
parallel  to  LIRC  A,  it  is  also  parallel  to  lIRC  B.  Therefore,  the  9 
records  for  LIRCs  which  are  parallel  to  one  another  will  contain  the 
same  LIRCs.  The  only  difference  is  which  LIRC  is  the  QCF  LIRC.  Also, 
either  the  QCF  LIRC  or  the  first  parallel  LIRC  will  have  the  minimum 
value  (numerical)  of  all  LIRCs  on  the  record.  Once  the  minimum  LIRC 
has  been  determined,  parallelism  can  be  found  by  checking  the  minimum 
LIRC  of  each  9 record  against  the  minimum  LIRCs  of  the  9 records 
already  read  and  stored.  If  a match  is  found,  the  parallel  indicator 
is  set  to  the  index  value  of  the  stored  9 record  which  is  parallel. 
Otherwise,  the  new  9 record  and  its  minimum  LIRC  are  stored  with  the 
previous  ones  and  will  be  used  in  checking  for  parallelism  if  more 
9 records  are  encountered. 


i 

I ' 
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A. 3. 6. 5 END  OF  QUESTION  PROCESSING 


After  all  QCF  records  for  a question  have  been  stored,  SCRM 
determines  whether  a B record  and  any  J records  had  been  found.  If  none 
were  found,  then  the  default  REPDEF  key  will  be  created  and  the  B flag 
set  to  1 . If  the  B flag  equals  1 and  no  J records  were  found  for  the 
question,  then  SCRM  will  access  the  REPDEF  File  using  the  key  already 
created.  First,  a LIRC  0000  J record  will  be  created  for  the  question. 
Then,  using  the  REPDEF  record  just  accessed,  J records  will  be  created 
for  all  print  LIRCs  on  the  REPDEF  record.  If,  however,  the  key  is 
invalid  and  is  not  the  default  key,  then  an  error  message  is  issued  and 
control  returns  to  the  Executive  Control  Module  (ECM).  If  the  invalid 
key  is  the  default  key,  no  error  message  is  given  and  the  J LIRC  process- 
ing is  bypassed. 

Next,  SCRM  will  determine  whether  any  9 records  were  found. 

If  some  were  found  and  parallelism  exists,  then  all  parallel  indicators 
set  by  QTM  for  the  L through  Z constraints  will  be  erased.  Only  those 
L-Z  LIRCs  which  are  also  on  the  9 record  used  for  parallelism  will  have 
their  parallel  indicator  set.  If  no  parallelism  was  found,  then  SCRM 
will  check  the  C and  J LIRCs  against  all  the  L-Z  LIRCs  to  see  if  paral- 
lelism can  be  established.  If  it  is  found,  then  the  above  procedure  of 
erasing  and  then  resetting  the  parallel  indicators  on  L-Z  records  will 
occur.  If  it  is  not  found,  then  all  L-Z  parallel  indicators  will  be 
erased  and  nothing  set.  Next,  C and  J parallel  indicators  will  be  set 
for  all  questions  that  have  parallelism. 

After  the  parallel  processing,  SCRM  will  finish  the  question 
by  writing  the  stored  records  on  the  new  QCF  in  the  following  order: 

(1)  L-Z  records 

(2)  B record  (if  it  exists) 

(3)  C,  J records  as  encountered  (or  created) 

(4)  A,  D,  H records  as  encountered 

Type  9 records  are  not  retained  on  the  new  QCF.  Processing  will  continue 
with  the  next  question. 


EXIT 


END  OF 
QUESTION 
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A. 4 TITLE;  FILE  SELECTION  MODULE  (FSM) 

A. 4.1  PURPOSE 

The  File  Selection  Module  (FSM)  identifies  which  of  the  several 
data  files  at  both  local  and  remote  facilities  contain  the  type(s)  of 
data  required  to  satisfy  the  query  constraints  and  respond  to  the  data 
requirements . 

The  File  Selection  Module  represents  the  initial  step  in  the 
NAVLIS  distributed  data  directory  approach.  This  approach  enables  the 
Executive  node  in  the  NAVLIS  system  to  determine  which  data  files  in 
the  system  contain  the  types  of  information  requested  in  the  query. 
Determination  of  the  specific  values  relating  to  that  file  is  made 
later  in  the  processing  cycle. 

The  principal  component  of  this  module  is  the  File  Content 
Directory  (FCD),  which  is  a sequence  of  records  that  describes  each 
data  file  in  the  NAVLIS  system  in  terms  of  its  data  elements  expressed 
as  Logistics  Information  Requirement  Codes  (LIRC)  (a  four-digit  code 
used  to  internally  represent  data  elements).  Since  the  FCD  describes 
data  files  by  data  type  (e.g.,  Federal  Stock  No.)  and  not  by  data  value 
(e.g.,  5490-112-7767),  it  will  be  able  to  identify  the  data  files 
containing  the  types  of  information  required  to  meet  query  constraints 
and  satisfy  query  data  requirements  but  not  necessarily  to  identify 
which  of  those  data  files  contains  the  particular  values  satisfying 
the  constraints. 

By  matching  the  data  and  constraint  LIRC  codes  passed  from  the 
Query  Translator  Module  with  the  file  content  LIRC  codes  in  the  FCD, 

FSM  will  be  able  to  determine  which  files  contain  the  type  of  data 
required  to  satisfy  certain  constraints  expressed  by  the  question  and 
can  meet  at  least  one  data  requirement. 

The  File  Selection  Module  will  use  the  question/group/set  logic 
determinations  performed  by  the  Query  Translator  Module  to  identify 
files  containing  data  of  the  type  required  to  satisfy  the  query. 

A data  file  will  qualify  for  value  searching  if  it  contains  at  least 
one  constraint  type  in  each  group  of  the  question  and  at  least  one  data 
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requirement  expressed  by  each  question.  For  queries  with  multiple 
questions,  this  procedure  will  be  repeated  for  each  question. 

Additionally,  the  FSM  is  responsible  for  the  only  access  veri- 
fication performed  by  the  Pilot  Model  (see  Section  8.1.6  for  discussion 
of  security  requirements).  The  NAVLIS  Pilot  Model  restricted  access 
at  the  file  level  through  character  identification  code  of  users. 

Contained  in  the  File  Content  Directory  are  "lock"  records  (one  for 
each  site  in  the  network)  associated  with  each  data  base  in  the  network. 

A. 4. 2 INPUTS 

Inputs  to  the  FSM  consist  of  the  following; 

• Query  records  generated  by  the  QTM  with  LIRC  codes  identify- 
ing the  query  constraints  and  data  requirements,  and 

• The  File  Content  Directory  (FCD)  identifying  the  LIRC  coded 

contents  of  the  systems  data  files.  The  entries  in  the  FCD 
contain:  for  the  content  record, 

a)  a file  identification 

b)  identification  of  the  facility 
at  which  the  file  is  located 

c)  a series  of  LIRC  codes,  in  numeric 
sequence,  tha'"  correspond  to  the 
LIRC  coded  fields  in  the  associated 
data  file. 

for  the  lock  record, 

a)  a file  identification 

b)  a facility  identification 

c)  a series  of  user  identifications  at 
that  facility  (b)  that  have  access 
to  that  file  (a) 

A. 4. 3 OUTPUTS 

The  FSM  produces  copies  of  the  query  constraint  file  generated 
by  QTM  for  use  in  retrieving  data  from  data  files  identified  as  candidates 
by  FSM.  For  each  candidate  data  file,  a copy  of  the  query  constraint 
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file  is  written  onto  a single  output  file.  That  copy  will  always  con- 
tain all  the  query  constraints,  but  only  those  data  selection  records 
that  request  data  contained  on  that  specific  data  file.  Each  copy 
generated  is  preceded  by  a record  identifying  the  file  to  which  that 
copy  applies.  All  copies  for  a particular  site  are  grouped  together 
and  preceded  by  a record  identifying  that  site. 

When  none  of  the  NAVLIS  data  files  can  satisfy  at  least  one  of 
the  constraints  in  each  question  group  as  well  as  at  least  one  data 
requirement,  the  user  is  notified  that  the  question  cannot  be  satisfied. 

A. 4. 4 RECORD  FORMATS  - (See  Figures  A1-A5  and  A9) 

A. 4. 5 STORAGE  REQUIREMENTS 

Program  (less  library  modules)  occupies  20,000  bytes  on  UNIVAC 
Series  70/45. 

A. 4. 6 PROCESSING  DESCRIPTION  (Refer  to  FSM  Flowchart,  page  70) 

The  FSM  is  called  by  the  Executive  Control  Module  (ECM)  after  the 
Query  Translation  Module  (QTM)  has  successfully  completed  processing. 

The  FSM  commences  by  allowing  the  user  to  input  file  parameters  or 
descriptors  that  describe  the  kinds  of  data  bases  of  interest.  The  user 
may  be  interested  in  a specific  subject  (e.g.,  aircraft  maintenance), 
or  organization  (e.g.,  COMNAVAIRPAC) , or  location  (e.g..  West  Coast), 
etc.  The  FSM  maintains  a parameter  table  associating  each  of  the  data 
bases  in  the  system  with  a list  of  parameters  describing  the  contents 
of  the  data  base  and  other  significant  data  base  characteristics. 

When  the  user  elects  to  input  file  parameters,  they  are  compared  with 
the  contents  of  the  file  parameter  table,  and  the  identification(s)  of 
the  data  base(s)  described  by  the  user  parameters  are  stored  in  an 
eligibility  table.  The  user  may  also  elect  not  to  specify  file  parameters, 
in  which  case  all  data  bases  in  the  system  are  eligible  for  further 
processing.  The  Query  Constraint  File  (QCF)  produced  by  QTM  is  then  read 
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into  an  internal  table  by  FSM  to  facilitate  rapid  execution  of  multiple 
reads  of  the  file.  Pilot  Model  constraints  on  the  size  of  the  QCF  made 
this  approach  feasible.  The  larger  size  of  the  QCF  in  an  operational 
mode  would  necessitate  an  alternative  method. 

The  following  sequence  of  operations  is  repeated  for  each  data  base 
identified  in  the  eligibility  table,  if  the  user  specified  file  parameters 
at  the  outset,  or  for  each  data  base  in  the  system,  if  no  file  parameters 
were  specified.  For  each  data  base  in  the  system,  the  FCD  contains  one 
or  more  lock  records  for  each  site  in  the  network  identifying,  by  user 
identification,  those  users  with  access  to  that  data  base.  The  lock 
records  are  followed  by  one  or  more  content  records  that  indicate  by 
LIRC  the  types  of  data  contained  in  that  data  base.  The  FSM  reads  the 
first  series  of  lock  records  in  the  FCD,  locating  the  record  whose  site 
identification  corresponds  to  the  site  identification  of  the  user  passed 
to  the  FSM  by  the  ECM.  The  user  identifications  contained  in  that  record 
are  compared  to  the  user  identification  also  passed  by  the  ECM.  Finding 
the  user  identification  in  the  lock  record  indicates  this  user  is 
authorized  to  retrieve  data  from  the  associated  data  base.  The  lock 
record  may  also  contain  the  value  "ALL"  instead  of  a series  of  user 
identifications,  indicating  that  no  access  restrictions  are  associated 
with  this  data  base.  If  neither  the  user  identification  nor  the  value 
"ALL"  is  found  in  the  lock  record,  the  FCD  is  read  until  the  series  of 
lock  records  for  the  next  data  base  is  encountered  and  the  access  vali- 
dation process  begins  for  that  data  base.  When  the  user's  identification 
or  the  value  "ALL"  is  encountered  in  a lock  record  for  the  user's  site, 
the  remaining  lock  records,  if  any,  are  skipped  until  the  content  record 
for  that  data  base  is  encountered. 

The  query  records  generated  by  QTM  are  then  accessed  and  the  LIRC 
codes  in  the  query  records  for  the  first  constraint  group  (Group  Field  L) 
are  compared  to  the  LIRC  codes  in  the  FCD  content  record.  If  at  least 
one  match  is  found,  the  LIRC  codes  in  the  query  records  for  the  next 
constraint  group  (Group  M,  if  the  query  contains  multiple  constraint 
groups)  are  compared  to  the  same  FCD  entry.  This  process  is  continued 
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until 

• A match  has  been  found  between  the  LIRC  codes  in  the 
FCD  content  record  being  processed  and  at  least  one 
constraint  LIRC  in  each  constraint  group  of  the  question, 
or 

• All  LIRC  codes  have  been  searched  and  no  match  has  been 
found  between  the  LIRC  codes  in  a constraint  group  and 
those  in  the  FCD  content  record. 

This  latter  situation  indicates  that  the  data  file  represented  by 
the  FCD  entry  currently  being  processed  does  not  contain  the  data  required 
to  satisfy  at  least  one  constraint  in  each  constraint  group  of  the 
question.  The  FSM  then  reads  to  the  next  series  of  lock  records  in  the 
FCD  to  begin  the  access  validation  processing  for  the  next  data  base. 

When  a match  is  found,  the  FSM  must  determine  whether  the  data 
file  represented  by  the  FCD  being  processed  satisfies  any  of  the  data 
requirements  expressed  by  the  question,  as  well  as  meeting  the  necessary 
constraint  conditions.  The  data  requirements  for  the  query  are  expressed 
in  the  query  records  with  a Group  field  of  "J",  "C",  or  "D".  The  FSM 
retrieves  the  LIRC  code  from  each  J,  C,  or  D group  query  record  and 
compares  it  to  the  LIRC  codes  in  the  FCD  entry  being  processed.  If  none 
of  the  LIRC  codes  identifying  data  requirements  of  the  questions  being 
processed  are  found  in  the  FCD  entry,  that  file  does  not  satisfy  any  data 
requirements,  even  though  the  data  file  represented  by  that  FCD  entry 
satisfies  the  question  constraint  conditions.  The  FSM  then  reads  to 
the  next  series  of  lock  records  in  the  FCD  and  begins  the  access  vali- 
dation and  content  comparison  for  the  next  data  base. 

When  the  FSM  finds  the  first  match  between  a data  requirement 
(Group  J,  or  C or  D if  there  are  no  J-records)  LIRC  code  and  a LIRC 
code  in  the  FCD  entry,  the  module  enters  the  identification  and  site 
location  of  the  data  base  represented  by  the  content  record  into  a 
Candidate  File  Table  (CFT).  The  entries  in  this  table  will  eventually 
represent  all  those  data  bases  in  the  NAVLIS  system  that  satisfy  the 
query  constraints  and  at  least  one  data  retrieval  requirement.  The 
LIRC  codes  of  each  of  the  data  requirements  satisfied  are  placed 
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sequentially  in  an  associated  table,  the  LIRC-Table.  The  LIRC-Table 
indices  indicating  the  first  and  last  LIRC  code  applying  to  the  data 
base  being  processed  are  entered  in  the  Candidate  File  Table  along 
with  the  data  base  identification  and  location. 

The  process  described  above  for  access  validation,  constraint 
satisfaction,  and  data  requirement  satisfaction  is  repeated  for  each 
data  base  in  theEl  igibility  Table  or  in  the  FCD.  When  the  FCD  records 
have  been  exhausted,  the  FSM  verifies  that  at  least  one  entry  has  been 
made  in  the  Candidate  File  Table;  if  not,  the  user  is  notified  that 
none  of  the  data  bases  in  the  system  contain  the  types  of  data  required 
to  respond  to  his  query.  When  entries  have  been  made  in  the  CFT,  the 
FSM  generates  an  output  file  containing  a copy  of  the  QCF  for  each 
candidate  data  base.  The  first  record  in  the  output  file  contains 
the  site  identification  and  file  identification  of  the  first  candidate 
data  base.  Each  of  the  constraint  records  on  the  QCF  and  the  data 
requirement  records  satisfied  by  the  data  base  are  duplicated.  Copies 
of  the  QCF  for  data  bases  at  any  single  site  are  contiguous  with  the 
first  record  for  that  location  containing  a site  identification  field. 
That  field  is  used  by  ECM  to  determine  the  location  in  the  network  to 
which  the  following  copies  of  the  QCF  are  to  be  transmitted.  The  first 
record  of  each  QCF  copy  contains  an  identification  of  the  data  base 
to  which  that  copy  applies. 
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QUESTION  NO. 


MERGE-START 


1 


A. 5 TITLE:  SYNONYM  RESOLUTION  MODULE  (SRM) 


A. 5.1  PURPOSE 

By  means  of  the  Synonym  Resolution  File  (SRF),  SRM  translates 
input  constraint  LIRCs  and  values  of  a query  to  the  equivalent  LIRCs 
and  values  which  are  contained  in  the  data  base(s)  being  processed. 
Since  each  site  has  its  own  SRF,  ECM  will  call  SRM  once  for  each  site 

A. 5. 2 INPUTS 

1.  IN-CONSTRAINTS  - Query  Constraint  File  (QCF)  as  it  was 
reformatted  and  output  by  the  File  Selection  Module  (FSM).  File 
contains  80-character  fixed  length  records. 

2.  SYNONYM-FILE  - Synonym  Resolution  File  (SRF)  for  the 
processing  site.  File  contains  800-character  fixed  length  records. 
Currently,  there  is  no  special  module  to  create  or  update  a SRF  for 
any  site.  SRF's  to  date  have  been  created  by  reading  in  10  data 
cards  and  creating  an  800-character  ISAM  record  from  them. 

A. 5. 3 OUTPUT 

CONSTRAINTS-OUT  - QCF  as  revised  by  SRM.  Records  are  still 
80-character  fixed  length.  Appropriate  LIRCs  and  data  values  have 
been  replaced  with  synonymous  LIRCs  and  values,  where  appropriate. 


A. 5.4  RECORD  FORMATS  - (See  Figures  A1-A5  and  A-10) 
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A. 5.4.1  SYNONYM  RESOLUTION  FILE  (SRF) 
A.  Fixed  Part 


Data  Field 

Posi tion 

Picture 

Values 

1 

Delete  Code 

1 

X 

SPACE  or  H-V 

2 

3 

Total  Chars 
Synonym  Key 

2-4 

9(3) 

014-800 

a.  File  ID 

5-7 

X(3) 

ALPHAN. 

b.  I/P  LIRC 

8-11 

X(4) 

NUMERIC 

c.  Tie  Breaker 

12-13 

X(2) 

ALPHAN.  (L-V  for  1st 
Rec  of  Key) 

4. 

Continuation 

14 

X 

SPACE  or  "X" 

- For 

continuation  records  skip  rest  of 

fixed  part  and 

go  to  variable  part  - 

5 

Synonym  LIRC 

15-18 

X(4) 

NUMERIC 

* 6. 

Inversion  Ind 

19-20 

9(2) 

00-09 

7. 

Type 

21 

X 

"I","R","N","A", 
"L"  or  SPACE 

8. 

No.  Decimals 

22 

X 

NUMERIC  or  SPACE 

9. 

« 

Count 

23-26 

9(4) 

NUMERIC 

i NOTE: 

t 

! 

i 

( 

Continuation  = 

Space  (Last  or  only  Rec  for  Key) 
"X"  (At  least  one  more  Rec) 

1 2. 

Inversion  Ind  = 

00  (Syn.  LIRC  is  not  inverted) 

= 

01-09  (Number  of  inverted  Chars 

for  Syn  LIRC) 

1 3. 

Type 

s 

I Syn.  LIRC  is 
R Syn.  LIRC  is 
N Syn.  LIRC  is 
A Syn.  LIRC  is 
L Syn.  LIRC  is 

Integer 
Real 
Numeric 
A1 phabetic 
Alphanumer. 
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4.  No.  Decimals 


5.  Count 


= 00-09  (No.  of  Decimal  places  in 
Real  Synonym  Value) 

= Space  - Syn.  Value  not  Real 

= Max.  size  for  Syn.  Value  (No.  of  characters) 


B.  Variable  Part 

1.  Char.  Count  Synonym  Value  - 01-99 

2.  Synonym  Value 

3.  No.  of  Input  Values  - 01-99 

4.  Char.  Count  I/P  Value  - 1 - 01-99 

5.  I/P  Value  - 1 

6.  Char.  Count  I/P  Value  - 2 - 01-99 

7.  I/P  Value  - 2 

Char.  Count  I/P  Value  - N - 01-99 
I/P  Value  - N 

- Continue  with  B-1  above  - 

NOTE:  Variable  part  of  continuation  records  must  start  with: 

1)  Char.  Count  Synonym  Value 
or  2)  No.  of  Input  Values 
or  3)  Char.  Count  Input  Value 

A. 5. 5 STORAGE  REQUIREMENTS 

Program  (less  library  modules)  occupies  10,000  bytes  on  UNIVAC 
Series  70/45. 

A. 5. 6 PROCESSING  DESCRIPTION  (Refer  to  SRM  Flowchart,  page  87) 
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A. 5. 6.1  GENERAL  DESCRIPTION 

The  Synonym  Resolution  Module  (SRM)  begins  processing  by 
reading  and  writing  Query  Constraint  File  (QCF)  records  until  the 
site  record  which  matches  the  site  value  passed  by  the  Executive 
Control  Module  (ECM)  is  found.  If  a matching  site  record  is  not 
found,  SRM  sets  an  error  indicator  and  passes  an  error  message  to 
ECM. 

All  C,  D,  J,  and  L-Z  records  are  processed  for  all  files 
of  the  site  as  they  are  encountered.  After  the  entire  site  has  been 
processed,  the  remaining  old  QCF  records  (if  any)  are  written  unchanged 
to  the  new  QCF. 

A. 5. 6. 2 ACCESSING  THE  SYNONYM  RESOLUTION  FILE 

To  access  the  Synonym  Resolution  File  (SRF),  SRM  sets  up  a 
key  consisting  of  file  identification,  QCF  LIRC,  and  a tie-breaker 
field.  If  the  key  for  a given  LIRC  of  an  old  QCF  record  is  not 
found  on  the  SRF,  the  old  QCF  record  is  written  on  the  new  QCF 
unchanged  and  the  next  QCF  record  is  read. 

A. 5. 6. 3 PROCESSING  C RECORDS 

A C record  may  have  one  or  two  LIRCs  which  are  checked  by 
SRM.  When  a match  is  found  for  a C LIRC  on  the  SRF,  the  synonymous 
LIRC,  type,  and  number  of  decimals  fields  will  replace  the  original 
ones  on  the  QCF  record. 

A. 5.6.4  PROCESSING  D RECORDS 

For  a D record  with  a matching  LIRC  on  the  SRF,  the  synonymous 
LIRC  and  count  field  replace  the  original  ones  on  the  QCF  record. 

A. 5. 6. 5 PROCESSING  0 RECORDS 

For  a J record  with  a matching  LIRC  on  the  SRF,  the  synonymous 
LIRC  replaces  the  original  one  on  the  QCF  record. 
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A. 5. 6. 6 PROCESSING  L-Z  RECORDS 


1- 

I 
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1 
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a.  General  Description  - For  a record  with  a type  of  L through  Z 
and  a matching  LIRC  on  the  SRF,  the  synonymous  LIRC  and  inversion 
indicator  replace  the  original  ones  on  the  QCF  record.  Then  the 
remainder  of  the  SRF  record  is  checked  for  a match  between  the  QCF 
search  value  and  an  SRF  input  value. 

(Note:  SRF  input  value  refers  to  a specific  data  field  on  the  SRF  record. 


b.  Description  of  QCF  and  SRF  Values  - A QCF  record  will  have  only 
one  search  value  unless  it  is  a ranging  search  (BE,  BN,  BL,  or  BH) 
in  which  case  it  will  have  exactly  two  search  values.  However, 
more  than  one  SRF  input  value  may  correspond  to  the  same  synonym 
value  and  there  may  be  any  number  of  synonym  values  on  the  SRF  for 
a given  LIRC. 

On  the  SRF  record,  each  input  value  and  synonym  value  field  is 
immediately  preceded  by  a character  count  (CC)  field  which  indicates 
how  long  a given  value  is.  (These  fields  are  all  variable  in  length.) 
There  is  also  a field  containing  the  number  of  input  values  for  a 
synonym  value.  This  field  precedes  the  CC  field  of  the  first  input 
value  for  the  synonym  value.  A total  number  of  characters  (TOT-CHARS) 
field,  which  contains  the  size  of  the  entire  SRF  record,  is  in  the 
fixed  portion  of  the  record.  For  the  first  record  of  a key,  the 
fixed  part  is  the  first  26  characters.  For  all  continuation  records, 
it  is  the  first  14. 


c.  Search  for  Matching  Values  - Since  a QCF  record  may  have  two 
search  values  which  will  be  checked  at  the  same  time,  two  hit 
indicators  (HITl  and  HIT2)  are  used.  HIT2  will  be  set  to  1 
(signifying  a match  has  already  been  found)  if  no  second  search 
value  occurs  on  the  QCF  record.  Before  beginning  to  search  for 
matching  values,  the  character  index  (INDEXS)  will  be  set  to  26 
(the  size  of  the  fixed  part  of  the  first  record  of  the  key.) 

If  no  values  are  on  the  SRF  record  (TOT-CHARS  = 26),  then  the 
original  search  value  is  retained  and  the  search  is  terminated. 
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If,  however,  synonym  and  input  values  are  present  on  the  SRF  record, 
then  the  following  steps  occur: 

(1)  CC  field  for  synonym  value  is  retrieved 

(2)  Synonym  value  is  stored 

(3)  Number  of  input  values  field  is  stored 

(4)  CC  field  for  input  value  is  retrieved 

(5)  Input  value  is  stored 

(6)  If  HITl  = 0,  the  input  value  (from  Step  5)  is 
compared  to  the  first  search  value  of  the  QCF 
record.  If  a match  occurs,  the  synonym  value 
(from  Step  2)  replaces  the  first  search  value 
on  the  new  QCF  record  and  HITl  is  set  equal 
to  1 . 

(7)  If  HIT2  = 0,  Step  6 is  carried  out  for  the 
second  search  value  and  HIT2  is  set  equal 
to  1 . 


After  step  7 has  been  executed,  the  process  continues  with 
Step  4,  retrieving  subsequent  input  values  and  testing  them, 
until  both  HITl  and  HIT2  = 1 or  no  more  input  values  exist  for 
the  synonym  LIRC.  If  the  former  occurs,  the  searching  is 
terminated.  In  the  latter  case,  the  process  continues  by  going 
back  to  Step  1 and  retrieving  the  next  synonym  value.  The  search 
for  a match  then  proceeds  as  it  did  for  the  first  synonym  value. 
If,  however,  there  are  no  more  synonym  values  for  the  key,  then 
a warning  is  issued  (via  ECM)  and  the  original  search  value  is 
retained  on  the  new  QCF  record. 

At  Steps  1,  3,  and  4,  a check  is  made  to  determine  whether 
the  end  of  the  SRF  record  has  been  reached  (i.e.  INDEXS  = TOT- 
CHARS).  When  this  occurs,  the  continuation  code  is  checked 
and  the  next  record  is  read,  if  appropriate. 

(Note:  A continuation  record  may  not  begin  with  the  synonym  value 

or  input  value  fields.  It  must  begin  with  the  CC  field  for  the 
synonym  value  or  the  CC  field  for  the  input  value  or  the  number 
of  input  values  field. ) 
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When  the  search  for  matching  values  terminates,  processing 
continues  by  reading  the  next  QCF  record.  (See  A. 4. 7.1) 

GENERAL  DESCRIPTION). 

A. 5. 6. 7 UNIVAC  VS  IBM 

The  only  difference  between  the  UNIVAC  and  IBM  versions  of 
SRM  is  in  accessing  the  SRF.  The  UNIVAC  uses  a RFAD. .. INVALID  KEY 
statement,  while  the  IBM  uses  a START  statement  followed  by  a READ. 
AT  END.  The  KEY  of  the  UNIVAC  version  is  the  one  described  in  G.2 
ACCESSING  THE  SYNONYM  RESOLUTION  FILE.  For  the  IBM  START,  the  KEY 
is  only  the  file  identification  and  the  QCF  LIRC.  The  tie  breaker 
field  is  not  used. 

To  date,  the  IBM  version  has  been  tested  only  as  a stand- 
alone process. 
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A. 5.7  COMMENTS  ON  SRM 
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Currently,  no  synonym  resolution  is  being  performed  on  L-Z  records  i| 

which  have  prefix,  partial,  or  suffix  searches  (except  for  prefix  searches 
which  have  been  converted  to  whole  ranging  searches  in  the  Screening  '■ 

Module  (SCRM)).  However,  it  is  worth  noting  that  synonym  resolution  is  J 

being  done  on  all  L-Z  records  with  whole  searches  regardless  of  the  i 

operator.  Synonym  resolution  for  operators  other  than  EQ  or  NE  may  be  i 

questionable. 

Synonym  resolution  is  performed  on  all  C LIRCs  regardless  of  the  j 

type  of  the  synonym  LIRC  or  the  computation  code.  This  could  create 
problems  if  the  synonym  LIRC  is  not  the  same  type  as  the  original  for 
most  computation  codes.  :i 

Synonym  resolution  on  D records  currently  has  no  effect  on  the 
query  because  the  Sort  Module  (SM)  gets  its  D record  information  from 
the  Query  Constraint  File  output  by  SCRM  (which  precedes  SRM).  Also, 
the  desirability  of  synonym  resolution  on  D records  for  queries  with 
multifile  hits  is  questionable. 

It  would  be  desirable  for  the  user  to  be  able  to  opt  for  no 
synonym  resolution  if  he  so  desires.  Also,  if  synonym  resolution 
is  desired,  the  user  should  be  given  the  options  of  automatic  resolu- 
tion, or  deciding  each  case  individually. 
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A. 6 TITLE;  PRELIMINARY  HIT  RESOLUTION  MODULE  (PHRM) 

A. 6.1  PURPOSE 

The  Preliminary  Hit  Resolution  Modules  (PHRM)  will  first 
determine  whether  preliminary  or  complete  hit  resolution  can  be 
done  for  the  given  data  base  for  all  the  appropriate  questions  of  the 
query.  If  so,  then  PHRM  creates  a file  of  hits  and/or  hit  candidates. 
If  not,  the  module  will  be  bypassed  and  all  hit  resolution  for  that 
data  base  will  be  done  by  the  Secondary  Hit  Resolution  Module  (SHRM). 

A. 6. 2 INPUTS 

A. 6. 2.1  CONSTRAINTS 

Query  Constraint  File  (QCF)  as  it  was  generated  by  the 
Synonym  Resolution  Module  (SRM).  File  contains  80-character  fixed 
length  records. 

A. 6. 2. 2 INV-MF(2) 

Inverted  Master  File  (INV-MF)  created  by  the  Invert  Update 
Program.  File  contains  644-character  fixed  length  records  in  the 
UNIVAC  version  and  293-character  fixed  length  records  with  10  records 
per  block  in  the  IBM  version. 

A. 6. 2. 3 REC-DESCRIPTION-FILE 

The  Record  Description  File  (RDF)  is  created  by  the  Invert 
Update  Program.  File  contains  46-character  fixed  length  records 
with  50  records  per  block. 

A. 6.3  INTERMEDIATE  FILES 

A. 6. 3.1  FILE-A,  FILE-B,  FILE-C,  FILE-D,  FILE-E,  FILE-F 

These  are  scratch  files  used  in  the  hit  merging  procedures. 
All  contain  54-character  fixed  length  records.  The  IBM  version  blocks 
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the  records  at  10  per  block;  UNIVAC  version  uses  the  default  blocking. 

A. 6. 3. 2 QSRT-1,  QSRT-2 

These  are  scratch  files  used  in  the  "quick"  sort/merge  pro- 
cedure. Both  contain  12-character  fixed  length  records  with  64  records 
per  block.  Currently,  these  two  files  exist  only  in  the  IBM  version. 

They  are  part  of  Program  Change  Proposal  (PCP)  #NC0118  which  has  not 
yet  been  put  into  the  UNIVAC  version. 

A. 6. 4 OUTPUT 

FILE-A,  FILE-B,  FILE-C,  FILE-D,  FTLE-E,  or  FILE-F  - The  output 
of  PHRM  will  be  one  of  the  above  six  files  depending  on  where  the  final 
merged  data  ended.  If,  however,  the  data  base  being  queried  is  a random 
file,  the  output  file  will  be  FILE-F.  The  above  files  are  the  same  files 
as  the  intermediate  files  which  have  the  same  names. 

Currently,  the  NAVLIS  system  can  handle  only  FILE-F  as  the 
output  file. 

A. 6. 5 RECORD  FORMATS  - See  Figures  A1-A5,  A11-A13 

A. 6. 6 STORAGE  REQUIREMENTS 

Program  (less  library  modules)  occupies  42,000  bytes  on  UNIVAC 
Series  70/45. 

A. 6. 7 PROCESSING  DESCRIPTION  (Refer  to  PHRM  Flowchart,  page  108) 

In  the  following  description  of  PHRM,  parenthesis  ( ) are  used 
to  enclose  statements  which  refer  to  the  IBM  version  only. 

A. 6.7.1  GENERAL  DESCRIPTION 

PHRM  begins  by  determining  whether  any  preliminary  hit  resolution 
can  be  done  for  the  data  base  being  processed.  If  no  resolution  can  oe 
done,  then  control  is  returned  to  the  Executive  Control  Module  (ECM)  with 
an  indicator  set  to  signify  no  hit  resolution  has  been  done.  There  is 
no  further  processing  by  PHRM  for  that  data  base. 
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Figure  A-13 


If,  however,  preliminary  hit  resolution  can  be  done,  then 
PHRM  begins  the  hit  resolution  by  opening  files  and  setting  the 
necessary  indicators  and  tables.  Then,  for  each  question,  the 
question  resolution  indicator  is  tested.  If  it  is  an  "N"  (no  resolu- 
tion), then  that  question  is  bypassed  and  the  next  one  processed. 

If  it  is  a "P"  (partial)  or  "C"  (complete),  then  the  hits  from  the 
previously  processed  question  are  added  to  the  final  hit  file,  unless 
that  question  is  to  be  merged  with  the  current  one.  In  that  case 
nothing  is  added  to  the  final  hit  file  until  the  entire  merged 
question  is  processed.  Next,  the  FIND-HITS  procedure  is  performed 
for  the  current  question.  After  each  question  is  processed,  PHRM 
will  check  to  see  if  there  are  any  more  questions  for  the  data  base. 

If  there  are  no  more,  then  the  remaining  hits  (if  any)  are  written 
to  the  final  hit  file  and  control  returns  to  ECM.  Otherwise,  process- 
ing continues  as  before  with  the  next  question  and  goes  on  until  none 
are  left. 

A. 6. 7. 2 PHRM-DET 

PHRM  determines  whether  any  preliminary  hit  resolution  is 
possible  by  first  finding  the  QCF  file  ID  record  for  the  data  base 
being  processed.  If  it  is  not  found,  then  control  returns  to  ECM. 
Otherwise,  PHRM  goes  through  all  the  constraints  for  the  data  base, 
storing  the  A and  L - Z records  and  setting  the  group  and  question 
resolution  indicators.  A group  can  have  either  complete  (C)  or  no 
(N)  hit  resolution.  Complete  group  resolution  occurs  only  when  all 
constraints  for  the  group  are  inverted  (i.e.,  inversion  indicator  = 0). 

A question  can  have  either  complete  (C),  partial  (P),  or  no  (N)  hit 
resolution.  If  all  groups  for  a question  are  "C",  then  the  question 
is  "C".  If  all  groups  are  "N",  then  the  question  is  "N".  For  questions 
having  groups  with  combinations  of  "Cs"  and  "NS",  the  resolution  will 
be  "P".  Currently,  no  preliminary  hit  resolution  is  done  on  any  question 
for  the  data  base  if  at  least  one  question  has  no  hit  resolution. 
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When  the  next  file  ID  record  is  read,  PHRM  moves  it  to  the 
NEXT-FILEID  field  for  ECM,  When  this  occurs  or  when  an  EOF  is  read 
on  QCF,  the  question  resolution  indicator  for  the  last  question  is 
set.  If  no  preliminary  hit  resolution  is  to  be  done,  control  will 
return  to  ECM  at  this  point, 

A. 6. 7. 3 FIND-HITS 

a.  Preliminary  - For  each  question  to  be  processed,  the  FIND-HITS 
Section  first  initializes  indicators.  Then  the  group  resolution 
indicator  is  tested  for  the  first  group.  If  it  is  an  "N",  that 
group  is  by-passed  and  the  group  resolution  indicator  of  the  next 
group  is  checked.  When  a group  with  a "C"  resolution  is  found, 
the  search  value(s)  from  the  first  constraint  of  the  group  is  (are) 
moved  to  the  corresponding  Working-Storage  areas  for  testing. 

b.  Create  INV-MF  Key  - Then  the  key  used  to  read  the  INV-MF  is 
created.  For  most  searches,  this  key  consists  of  the  LIRC  followed 
by  the  first  nine  inversion  characters  of  the  (first)  search  value 
and  a two-character  tie-breaker  field  which  is  initialized  as  low- 
values.  If  the  search  value  is  inverted  on  less  than  nine  characters, 
then  the  remainder  of  that  field  is  low-value  filled.  Also,  for 
LE,  LS,  and  NE  operation  codes  (op  codes)  or  any  non-whole  searches, 

’ the  inversion  character  field  is  all  low-values. 

J 

i c.  Read  INV-MF  - (For  the  IBM  version,  random  access  is  achieved 

i by  a START  ...  INVALID  KEY  on  the  INV-MF.  The  key  is  actually 

i a generic  key.  It  does  not  contain  the  tie-breaker  field  or  any 

i of  the  low-value  filler  of  the  inversion  field.  At  the  very  least, 

‘ the  key  will  be  the  LIRC.  When  an  invalid  key  occurs,  PHRM  attempts 

another  START  using  one  less  character  from  the  right  side  of  the 
? key  if  the  op  code  was  not  EQ  or  the  LIRC  was  equal  to  "0000"  or 

the  key  was  not  just  the  LIRC.  Should  an  invalid  key  occur  again, 

> the  process  continues  until  either  the  key  is  valid,  or  the  invalid 

key  consists  only  of  the  LIRC.  When  a valid  key  is  found,  processing 
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continues  with  reading  the  INV-MF  record.  Otherwise,  PHRM  goes 
to  the  Next-Constraint  procedure  (Section  A.6.7.3F)). 

For  the  UNIVAC  version,  the  READ  ...  INVALID  KEY  format  is 
used.  When  the  invalid  key  occurs,  the  next  record  is  read 
sequentially.  If  it  is  for  the  proper  LIRC,  it  goes  to  the 
Searches  procedure  (Section  A. 6. 7. 3d);  otherwise,  processing 
resumes  with  the  Next-Constraint  (Section  A.6.7.3f). 

d.  Searches  - After  a valid  read  is  executed,  the  full  value  of 
the  INV-MF  data  value  field  is  moved  to  a Working-Storage  area. 

(For  a suffix  search,  the  data  value  is  shifted  to  the  left  until 
the  number  of  data  characters  remaining  equals  the  number  in  the 
suffix  search  value.  Then  the  right  side  of  the  data  value  field 
is  space-filled. ) 

For  a prefix  or  partial  search,  the  characters  of  the  data 
value  which  correspond  to  those  characters  of  the  search  value 
that  are  equal  to  asterisks  (*)  are  changed  to  asterisks. 

(Then,  that  portion  of  the  data  value  field  which  is  greater 
than  the  size  of  the  prefix  or  partial  search  value  is  space-filled.) 

e.  Test-Data-Val ue  - The  data  value  from  the  INV-MF  (which  may 
have  been  altered)  is  compared  to  the  search  value  using  the  given 
op  code.  If  a hit  occurs,  all  the  logical  record  numbers  (LRN's) 
for  the  hit  value  are  retrieved  for  subsequent  merging,  (see  Section 
5,  (MERGE-HITS))  except  if  ..IRC  = 0000,  when  only  the  data  value, 
which  is  also  the  LRN,  that  was  a hit  is  retrieved.  For  whole 
searches  with  GE  or  GR  op  codes,  subsequent  LRN's  for  the  same 

LIRC  are  also  retrieved  without  further  value  tests.  If  the  op  code 
equals  NE  or  the  search  type  is  not  whole,  all  the  remaining  INV-MF 
records  for  the  LIRC  being  processed  are  checked;  otherwise,  process- 
ing continues  with  the  Next-Constraint  Section  A.6.7.3f).  For 
non-hits  with  op  codes  equal  to  GE,  GR,  or  NE,  or  those  which  are 
not  whole  searches,  testing  continues  with  the  next  INV-MF  record. 
(For  LIRC  = 0000,  next  LRN  is  processed  instead).  All  other  non- 
hits go  to  Next-Constraint. 
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f.  Next-Constraint*  - (If  there  are  no  more  constraints,  PHRM 
goes  to  the  In-Core  Sort  (Section  A.6.7.3g).  If  the  next  question 
is  not  equal  to  the  current  one,  or  if  the  next  group  is  not  equal 
to  the  current  group,  the  ANALIZE-GROUP  logic  is  performed 
(Section  A. 6. 7. 4).  Processing  then  continues  with  the  In-Core  Sort 
(Section  A.6.7.3g).  If  both  the  next  question  and  the  next  group 
are  equal  to  the  current  question  and  group  and  the  logical  connector 
is  an  "or"  (as  determined  by  ANALIZE-GROUP),  then  the  search  value(s) 
is  (are)  moved  to  Working-Storage  and  PHRM  control  goes  to  Create 

^ INV-MF  Key  (Section  A. 6. 7)). 

g.  In-Core  Sort  - For  a pair  of  constraints  not  connected  by  an 
"or"  operator,  an  in-core  sort  is  performed  on  the  table  of  hit 
candidates  retrieved  so  far. 

h.  Merging  - Then,  if  there  are  no  more  constraints,  or  if  the 
next  constraint  has  a different  Query  ID  or  Question  Number,  all 
levels  of  merging  are  performed  (i.e.  MRG  - CONSTRAINTS,  MRG-SETS, 
MRG-GROUPS,  MRG-QUESTIONS) . If  there  are  no  hits  for  the  question, 
the  no  hits  error  message  is  generated  and  control  returns  to  ECM. 

If  there  are  hits,  then  processing  continues  with  the  next  question. 
(See  Section  A. 6. 7.1  GENERAL  DESCRIPTION). 

If  the  next  group  is  not  equal  to  the  previous  group,  merging 
is  done  to  the  MRG-GROUPS  level.  If  there  are  no  hits  for  the 
group  (which  signifies  no  hits  for  the  question),  then  the  no  hits 
error  message  is  generated  and  control  returns  to  ECM.  Otherwise, 

PHRM  control  goes  to  test  the  next  group  resolution  indicator 
(Section  A. 6. 7. 3a  - Preliminary). 

If  the  next  set  is  not  equal  to  the  previous  set,  then  merging 
is  done  to  the  MRG-SETS  level  and  processing  continues  with  the 
next  group  resolution  indicator  test;  otherwise  only  the  MRG-CON- 
STRAINTS  procedure  is  performed  before  continuing  with  the  group 
resolution  indicator  check. 

* f^nr  UNIVAC  version,  Next-Constraint  begins  with  Merging  (Section  3h). 
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i.  "A"  Record  Processing  - Whenever  an  A record  is  encountered, 
the  merge  indicator  is  set  to  1 to  signify  a merge  is  in  progress, 
or  to  0 to  indicate  the  end  of  a merge.  After  setting  the  indicator, 
the  next-constraint  is  processed. 

A. 6. 7.4  ANALIZE-GROUP 

Whenever  the  next  constraint  to  be  processed  is  not  of  the 
same  question  or  group  as  the  previous  constraint,  then  the  ANALIZE- 
GROUP  Section  is  performed.  This  section  of  coding  checks  to  see 
that  no  constraints  in  the  up-coming  group  are  efficiency  searches 
and  all  are  connected  by  the  "or"  operator  (i.e.,  set  numbers  are  not 
equal).  If  this  is  the  case,  the  group  condition  indicator  is  0; 
otherwise,  it  is  set  to  1. 

A. 6. 7. 5 MERGE-HITS 

When  the  comparison  of  a data  value  and  search  value(s) 
results  in  a hit,  then  the  Merge  Hits  processing  takes  place.  Each 
LRN  from  the  hit  INV-MF  record  is  retrieved  and,  with  the  line  count 
(LC),  is  used  to  create  a Record  ID.  (The  LRN  is  then  checked  to 
see  if  it  is  within  the  range  of  the  HI/LO  indicators.  If  it  is  out 
of  range  and  the  LIRC  is  equal  to  "0000",  then  some  indicators  are 
set  and  MERGE-HITS  is  completed  for  the  LRN.  if  it  is  out  of  range 
and  the  LIRC  is  not  equal  to  "0000",  then  the  remaining  LRN's  for 
that  record  and  any  subsequent  continuation  records  are  checked. 

If  the  LRN  is  within  range,  then  the  output  hit  file  (OUT)  is  opened 
and  the  appropriate  switches  and  indicators  are  initialized  (if  this 
has  not  already  been  done).  Next,  the  size  of  the  in-core  sort  table 
is  checked.  If  it  is  already  full  (currently,  4000  entries),  then  it 
is  sorted  (see  Section  A.6.7.3g,  In-Core  Sort)  and  its  index  is  reset. 
Then,  the  parallel  indicator  is  checked.  If  the  constraint  is  not 
parallel,  the  LC  field  is  spaced  out.  Now,  the  record  is  moved  to 
the  next  entry  of  the  in-core  sort  table.)**  If  the  LIRC  is  equal  to 

**  For  the  UNIVAC  version,  an  OR-MERGE  is  performed  on  the  hits  being 
retrieved  for  the  constraint  and  any  others  which  may  have  already 
been  retrieved. 
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"0000",  then  MERGE-HITS  is  complete  since  PHRM  must  test  each  LRN  for 
a LIRC  "0000"  constraint.  Otherwise,  the  next  LRN  is  retrieved  and 
processed  as  before.  When  all  the  LRN's  have  been  retrieved  for  a 
record,  the  continuation  code  is  checked.  If  there  are  one  or  more 
continuation  records,  then  the  LRN's  from  them  are  also  retrieved  and 
processed.  When  no  more  LRN's  are  left  on  the  last  continuation  record, 
then  some  indicators  are  set  and  MERGE-HITS  is  complete  for  the  data 
value  processed. 

A. 6. 7.6  MRG-CONSTRAINTS 

This  procedure  merges  at  most  two  files  which  contain  sorted 
hits  at  the  constraint  level.  That  is,  each  file  contains  only  the 
hits  from  one  constraint  record  and  the  merging  being  done  is  for  the 
same  group  and  the  same  set.  The  older  of  the  two  files  is  denoted  by 
CON-INDIC  and  the  newer  by  HIT-INDIC  (sorted  output  of  Merge-Hits 
procedure).  If  there  is  no  older  file,  then  HIT-INDIC  is  moved  to  OUT 
(the  indicator  for  the  resultant  hit  file)  and  no  actual  merging  is 
done.  If,  however,  two  files  are  present  and  neither  is  an  efficiency 
file,  an  AND-MERGE  is  done.  An  efficiency  is  one  which  contains  LRN's 
that  are  not  hits.  If  both  files  are  efficiency  files,  then  an  OR- 
MERGE  is  performed  and  the  resultant  file  is  still  an  efficiency  file. 

If  only  one  file  is  an  efficiency  file,  then  a NOT-MERGE  is  performed. 
For  the  NOT-MERGE,  the  resultant  file  is  not  an  efficiency  file. 

After  the  merging  (if  any),  OUT  becomes  the  new  CON-INDIC.  Then  OUT 
and  HIT-INDIC  are  reset  to  zero. 

A. 6. 7. 7 MRG-SETS 

This  procedure  merges  at  most  two  files  which  contain  sorted 
hits  at  the  set  level.  That  is,  each  file  contains  only  hits  from  one 
set  and  the  merging  being  done  is  for  the  same  group  but  different  sets. 
The  older  of  the  two  files  is  denoted  by  SET-INDIC  and  the  newer  by 
CON-INDIC.  If  there  is  no  older  file,  then  CON-INDIC  is  moved  to  OUT 
and  no  merging  is  done.  If,  however,  two  files  are  present  and  neither 
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is  an  efficiency  file,  an  OR-MERGE  is  done.  If  both  files  are  effi- 
ciency files,  then  an  AND-MERGE  is  performed  and  the  resultant  file 
is  an  efficiency  file.  If  only  one  file  is  an  efficiency  file,  then 
a NOT-MERGE  is  performed  and  the  resultant  file  is  still  an  efficiency 
file.  After  the  merging  (if  any),  OUT  becomes  the  new  SET-INDIC. 

Then  OUT  and  CON-INDIC  are  reset  to  zero. 

A. 6. 7.8  MRG-GROUPS 

This  procedure  merges  at  most  two  files  which  contain  sorted 
hits  at  the  group  level.  This  is,  each  file  contains  only  hits  from 
one  group  and  the  merging  being  done  is  for  the  same  question  but 
different  groups.  The  older  of  the  two  files  is  denoted  by  GRP-INDIC 
and  the  newer  by  SET-INDIC.  If  there  is  no  older  file,  then  SET-INDIC 
is  moved  to  OUT  and  no  actual  merging  is  done.  If  two  files  are  present 
and  neither  is  an  efficiency  file,  then  an  AND-MERGE  is  done.  If,  how- 
ever, both  files  are  efficiency,  then  an  OR-MERGE  is  performed  and  the 
resultant  file  is  an  efficiency  file.  If  only  one  file  is  an  efficiency 
file,  then  a NOT-MERGE  is  performed  and  the  resultant  file  is  not  an 
efficiency  file.  After  the  merging  (if  any),  OUT  becomes  the  new 
GRP-INDIC.  Then  the  HI/LO  indicators  are  set  and  OUT  and  SET-INDIC 
are  reset  to  zero. 

A. 6. 7. 9 MRG-QUESTIONS 

This  procedure  merges  at  most  two  files  which  contain  sorted 
hits  at  the  question  level.  That  is,  each  file  contains  only  hits 
from  one  question  and  the  merging  being  done  is  for  the  same  question 
or  set  of  merged  questions.  The  older  of  the  two  files  is  denoted  by 
QST-INDIC  and  the  newer  by  GRP-INDIC.  If  there  is  no  older  file, 
then  GRP-INDIC  is  moved  to  OUT  and  no  actual  merging  is  done.  If, 
however,  two  files  are  present,  then  an  OR-MERGE  is  done.  After  the 
merging  (if  any),  OUT  becomes  the  new  QST-INDIC.  Then  OUT  and 
GRP-INDIC  are  reset  to  zero.  If  the  question  processed  is  not  part 
of  a merged  question,  if  it  is  the  last  in  a merged  question,  or  if 


there  are  no  more  questions  to  process,  then  PHRM  goes  to  WRITE-HIT- 
FILE;  otherwise,  it  processes  the  next  question. 


A. 6. 7. 10  OR-MERGE 

a.  General  Description  - For  the  OR-MERGE  (and  the  AND-MERGE), 
INI  (the  first  input  file)  represents  the  older  of  the  two  hit 
candidate  files  being  merged,  and  IN2  (the  second  input  file) 

is  the  newer.  For  all  merges,  OUT  is  the  resultant  output  file. 
In  the  OR-MERGE,  duplicate  LRN's  with  the  same  LC  are  eliminated 
(except  if  two  questions  with  partial  hit  resolution  are  being 
merged).  If  the  LRN's  are  the  same  but  the  LC's  are  different, 
both  hits  are  retained  unless  exactly  one  is  a parallel  record 
(LC  t spaces),  in  which  case  only  the  parallel  record  is  retainec 
Two  exceptions  are;  (1)  If  the  parallel  one  had  only  partial 
hit  resolution  but  the  non-parallel  had  complete,  then  both 
would  be  retained,  and  (2)  if  both  input  files  are  efficiency 
files,  then  the  non-parallel  one  is  retained. 

b.  Preliminary  Processing  - If  there  is  no  IN2  file,  then  all 
of  INI  is  copied  to  OUT  and  the  OR-MERGE  is  not  performed. 

If  INI  and  IN2  do  not  intersect  (as  determined  by  the  HI/LO 
logic),  then  no  OR-MERGE  is  necessary.  First,  all  the  hits 
from  the  file  with  the  lower  LRN's  are  written  to  OUT,  then 
all  the  hits  from  the  remaining  file  are  written  to  OUT. 

c.  OR-MERGE-LOOP  - PHRM  merges  INI  with  IN2  onto  OUT  in  the 
following  manner: 

(1)  If  an  end-of-file  is  read  on  either  input  file,  then 
the  remainder  of  the  other  file  is  written  to  OUT  and  the 
OR-MERGE  is  complete. 

(2)  If  INl-LRN  ' IN2-LRN,  then  the  INI  record  is  moved  to 
OUT  and  the  next  INI  record  is  retrieved. 
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(3)  If  either  the  INI  file  or  the  IN2  file  are  from 
questions  which  have  only  partial  hit  resolution,  then 
go  to  OR-qST-MERGE  (Section  A.6.7.10d). 

(4)  If  INl-LRN  IN2-LRN,  then  the  IN2  record  will  go 
on  OUT.  But,  first,  the  LC  field  is  spaced-fi 1 led  if 
IN2  is  not  a file  with  parallel  hits;  or  if  two  questions 
are  being  merged,  the  question  number  of  the  first  is 
used.  Then,  the  resultant  IN2  record  is  written  to 

OUT  and  the  next  IN2  record  is  retrieved. 

(5)  If  INl-LRN  = IN2-LRN  and  INl-LC  = Spaces,  then 
the  INI  record  is  written  to  OUT  and  the  next  INI 
and  IN2  records  are  retrieved. 

(6)  If  INl-LRN  = IN2-LRN  and  both  INI  and  IN2  are 
efficiency  files  and  either  INl-LC  or  IN2-LC  = space 
(not  parallel),  then  the  next  record  from  the  file 
which  is  parallel  is  retrieved. 

(7)  If  INl-LRN  = IN2-LRN  and  INl-LC  = spaces,  then 

the  IN2  reocrd  will  go  on  OUT.  But,  first,  the  LC  field 

is  spaced-fi 1 led  if  IN2  is  not  a file  with  parallel  hits; 
or  if  two  questions  are  being  merged,  the  question  number 
of  the  first  is  used.  Then  the  resultant  IN2  record  is 
written  to  OUT  and  the  next  INI  ’nd  IN2  records  are 
retrieved. 

(8)  If  INl-LRN  = IN2-LRN  and  IN2-LC  = spaces,  then  the 

INI  hit  is  written  to  OUT  and  the  next  INI  and  IN2  records 

are  read. 

(9)  It  INl-LRN  = IN2-LRN  and  INl-LC  < IN2-LC,  then  the 
INI  hit  is  moved  to  OUT  and  the  next  INI  record  is  read. 

(10)  If  INl-LRN  = IN2-LRN  and  INl-LC  = IN2-C,  then  the 
INI  hit  is  moved  to  OUT  and  the  next  INI  and  IN2  records 
are  retrieved. 
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(11)  If  INl-LRil  = IN2-LRN  and  INl-LC  IN2-LC,  then  the 
IN2  record  will  be  moved  to  OUT,  But,  first  if  two  questions 
are  being  merged,  the  question  number  of  the  first  question 
is  used.  Then  the  resultant  IN2  record  is  written  to  OUT 
and  the  next  IN2  record  read. 

d.  OR-QST-MERGE  - (Section  A.6.7.10b3  for  routes  which  send 

coding  here). 

(1)  If  INl-LRN  ' IN2-LRN,  then  the  IN2  record  is  written 
to  OUT  and  the  next  IN2  record  is  read. 

(2)  If  INl-LRN  = IN2-LRN  and  INl-LC  ^ IN2-LC,  then  INI 
is  written  to  OUT  and  the  next  INI  record  is  retrieved. 

(3)  If  INl-LRN  = IN2-LRN  and  INl-LC  = IN2-LC,  then  if 
both  LC's  are  parallel  and  either  the  INI  or  IN2  file 
contains  hits  from  a question  with  complete  hit  resolution, 
the  next  record  of  the  file  without  complete  hit  resolution 
is  read.  Otherwise,  both  the  INI  and  IN2  records  are 
written  to  OUT  and  the  next  record  from  both  input  files 

is  read. 

(4)  If  INl-LRN  = IN2-LRN  and  INl-LC  > IN2-LC,  then  the 
IN2  record  is  written  to  OUT  and  the  next  IN2  record  is 
read. 

A. 6. 7. 11  AND-MERGE 

a.  General  Description  - In  the  AND-MERGE,  only  matching  hits 
are  retained.  To  match,  both  LRN's  must  be  the  same  and  either 
both  EC’s  are  the  same  or  one  is  spaces.  If  one  is  spaces,  then 
the  other  LC  (parallel  one)  is  the  hit. 

b.  Preliminary  Processing  - In  performing  an  AND-MERGE,  PHRM 
starts  by  first  determining  if  there  is  an  IN2  file.  If  not, 
then  no  hits  are  possible  so  the  AND-MERGE  is  not  performed. 
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If  the  INI  and  IN2  files  do  not  intersect  (as  determined  by  the 
HI/LO  logic),  then  no  hits  are  possible  and,  again,  no  AND-MERGE 
is  done. 

c.  AND-MERGE-LOOP  - PHRM  merges  INI  with  IN2  onto  OUT  in  the 
following  manner: 

(1)  If  an  end-of-file  is  read  on  either  input  file,  then 
the  AND-MERGE  is  complete. 

(2)  If  INl-LRN  IN2-LRN  or  INl-LRN  IN2-LRN,  then  nothing 
is  put  on  OUT,  and  the  next  record  of  the  file  which  had  the 
lower  LRN  is  read. 

(3)  If  INl-LRN  = IN2-LRN  and  INl-LC  = IN2-LC,  then  the 
INI  record  is  written  to  the  OUT  file  and  the  next  record 
from  both  input  files  is  read. 

(4)  If  INl-LRN  = IN2-LRN  and  INl-LC  f IN2-LC  and  (INl-LC  = 
spaces  (not  a parallel  file)  or  IN2-LC  = spaces),  then  the 
parallel  record  is  a hit.  Since  non-parallel  records  with 
the  same  LRN  could  exist,  only  the  parallel  input  file  is 
read  again. 

(5)  If  INl-LRN  = IN2-LRN  and  (INl-LC  IN2-LC  or  INl-LC 
IN2-LC)  (but  neither  LC  = spaces),  then  there  is  no  hit 
and  either  the  next  INI  or  IN2  record  is  retrieved  depend- 
ing on  which  LC  was  lower. 

A. 6. 7. 12  NOT-MERGE 

a.  General  Description  - For  the  NOT-MERGE  with  an  AND  operator 
(MRG-GROUPS,  MRG-CONSTRAINTS) , INI  represents  the  input  file  with 
hit  candidates  and  IN2  represents  the  efficiency  input  file  (not 
hits).  For  the  NOT-MERGE  with  an  OR  operator  (MRG-SETS),  the 
opposite  is  true.  INI  is  the  efficiency  file  and  IN2  is  the  hits. 
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In  the  NOT-MERGE,  the  only  LRN's  which  are  candidates  for  the  OUT 
file  are  those  on  INI.  IN2  is  used  solely  to  eliminate  hits  from 
INI. 

b.  Preliminary  Processing  - If  there  is  no  INI  file,  then  there 
are  no  hits  so  NOT-MERGE  is  not  performed.  If  there  is  no  IN2 
file,  or  if  the  INI  and  IN2  files  do  not  intersect  (as  determined 
by  the  HI/LO  logic),  then  all  the  records  on  INI  are  hits  and  are 
written  to  OUT  and  the  NOT-MERGE  is  not  performed. 

c.  NOT-MERGE-LOOP  - PHRM  merges  INI  with  IN2  onto  OUT  in  the 
following  manner: 

(1)  If  an  end-of-file  is  encountered  on  either  input  file, 
then  the  remainder  of  INI  (if  any)  is  written  to  OUT 
and  the  NOT-MERGE  is  complete. 

(2)  If  INl-LRN  IN2-LRN,  then  the  INI  record  is  written 
to  the  OUT  file  and  the  next  INI  record  is  read. 

(3)  If  INl-LRN  IN2-LRN,  then  nothing  is  put  on  OUT  and 
the  next  IN2  record  is  read. 

(4)  If  INl-LRN  = IN2-LRN  and  (IN-LC  = IN2-LC  or  INl-LC  = 
spaces  (not  parallel)),  then  the  INI  record  is  not  a 
hit,  and  the  next  INI  and  IN2  records  are  retrieved. 

(5)  If  INl-LRN  = IN2-LRN  and  IN2-LC  = spaces  (not  parallel), 
then  the  INI  record  is  not  a hit.  Since  the  next  INI 
record  could  also  have  the  same  LRN  but  with  a different 
LC,  only  the  next  INI  record  is  read. 

(6)  If  INl-LRN  = IN2-LRN  and  INl-LC  IN2-LC  (but  neither 
LC  = spaces,  then  the  INI  record  is  a hit  and  the 
next  INI  record  is  retrieved. 

(7)  If  INl-LRN  = IN2-LRN  and  INl-LC  IN2-LC  (but  neither 
LC  = spaces),  then  no  hit  exists,  but  the  next  IN2 
record  is  read. 
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A. 6. 7. 13  WRITE-HIT-FILE 

This  procedure  writes  the  final  hits  from  a question*  to  an 
output  hit  file.  If  the  data  base  is  a random  file,  the  hits  are 

ordered  by  question,  so  no  merging  is  necessary.  As  each  question  is 

completed,  its  hits  are  written  to  the  same  file  (FILE-F).  If,  however, 
the  data  base  is  sequential,  then  the  previous  output  hit  file  (if  any), 
which  is  indicated  by  QRY-INDIC,  is  merged  with  the  present  one,  which 
is  indicated  by  QST-INDIC.  Hits  are  ordered  by  LRN,  Question  Number, 

LC.  The  resultant  file  becomes  the  new  QRY-INDIC  file. 

Regardless  of  the  data  base  type,  a Record  Description  File 

(RDF)  may  be  associated  with  the  data  base.  If  so,  before  the  hit  is 

transferred  to  the  output  file,  the  RDF  file  is  accessed  using  the  LRN 
as  the  key.  Should  an  invalid  key  occur,  an  error  message  is  generated 
and  control  returns  to  ECM.  Eventually,  it  comes  back  to  PHRM  and 
simply  by-passes  the  processing  of  the  bad  LRN.  When  a valid  key  is 
found,  the  physical  record  key  (PRK)  and  number  of  physical  records 
per  logical  record  (NO-PR)  are  added  to  the  hit  record.  This  is  done 
for  all  hits.  If  the  data  base  does  not  have  an  RDF,  then  PRK  equals 
LRN,  and  NO-PR  equals  spaces. 

A. 6. 7. 14  UNIVAC  vs.  IBM 

The  differences  between  the  UNIVAC  and  IBM  versions  of  PHRM 
are  as  follows: 

(a)  The  IBM  version  accesses  the  INV-MF  with  a START... 
INVALID  KEY,  whereas  the  UNIVAC  version  uses  a 
READ. .. INVALID  KEY.  Also,  the  IBM  key  does  not 
include  the  tie-breaker  field  and  in  some  instances 
does  not  even  include  the  entire  search  value. 

(See  Read  INV-MF,  Section  A. 6. 7. 3c). 

(b)  The  IBM  version  contains  Program  Change  Proposals 
(PCP's)  which  have  not  yet  been  added  to  the  UNIVAC 
version.  Some  PCP's  correct  errors  and  others 
enhance  the  PHRM  processing. 
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A. 7 TITLE;  ADS  INTERFACE  MODULES 


The  following  are  all  ADS  Modules; 


NLDLADS 

NLDPADS 

ADSFACE 

ADS370 

ADS7045 

ADSSHRM 


ADS  Module  at  DPSCLANT 
(never  installed) 

ADS  Module  at  DPSCPAC 

ADS  Module  at  NMCSA 

Test  Version  of  ADSFACE 

Test  Version  of  NLDPADS 

ADSFACE  with  PCPs  for  Test 


A. 7.1  PURPOSE 

The  ADS  Modules  perform  the  function  of  bridging  the  gap  between 
the  uniquely  formatted  data  files  resident  at  a site  and  the  remainder 
of  the  generalized  NAVLIS  system.  By  providing  a standard  interface, 
the  burden  of  coping  with  non-standardization  is  shifted  away  from 
other  NAVLIS  modules.  In  addition  to  reformatting  the  site's  records, 
conversions  of  data  fields  are  performed.  In  particular,  dates  are 
converted  from  Julian  to  calendar  formats. 

In  a sense,  each  ADS  module  is  uniquely  designed  to  process  a 
specific  file.  Much  of  the  program  logic  is  the  same,  however. 

In  fact,  differences  between  the  modules  are  small.  Major 
differences  occur  only  in  the  access  requirements  for  the  site  files. 
Processing  of  the  constraint  and  hit  files  is  common  to  all  versions, 
as  would  be  the  SHRM  Implementation. 

Originally,  secondary  hit  resolution  was  to  be  performed  in  a 
separate  module,  SHRM.  A PCP  to  be  described  provides  this  function 
as  an  enhancement  directly  to  the  ADS  modules. 


A. 7. 2 INPUT 

To  define  the  query  being  processed,  the  Query  Constraint  File 
created  by  FSM,  or  if  applicable  SRM,  is  supplied  to  the  ADS  Interface 
Module.  Hit  resolution  performed  by  PHRM  is  supplied  through  the 
Hit  File.  This  file  indicates  which  records  are  hits  if  complete 
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resolution  is  performed  by  PHRM,  Otherwise  the  records  are  candidates 
with  final  resolution  to  be  performed  in  the  ADS  Interface  Module. 

A.  7. 3 OUTPUT 

Output  of  an  ADS  Interface  Module  consists  of  a series  of  Response 
Records  passed  one  at  a time  back  to  ECM/RCM.  Each  record  contains  the 
LIRC  and  data  value  of  a field  required  either  in  printing  a report  or 
performing  a computation. 

In  addition,  a count  of  hits  by  question  is  supplied  to  ECM/RCM 
as  well  as  Return  and  Error  Indicators. 

A. 7. 4 RECORD  FORMATS  - Response  Records  returned  to  ECM/RCM  have  the 
following  format  (See  Figure  A7) 


Bytes 

Data  Field 

1-3 

Query  ID 

4-6 

Question  Number 

8 

Asterisk  Flag  for  non-printed  items 

9 

Type  Code:  C,D,  or  J 

10-11 

Set  Number 

13-16 

LIRC 

17-18 

Length  of  value  in  characters 

19-114 

LIRC  Value 

Hit  File  Records 

have  the  format  - (See  Figure  A13) 

^tes 

Data  Field 

1-3 

Query  ID 

4-6 

Question  Number 

7-8 

Search  Type  Code 

9 

Constraint  Type  Code  (L-Z) 

10-11 

Set  Number 

15 

Whole/Prefix  Search  Switch 

16-19 

LIRC 

27 

Parallel  Indicator,  P if  parallel 
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28 

29-78 


Efficiency  Search  Indicator,  Space  for 
not  efficiency  search 

Search  Value 


C-Type  Records  (See  Figure  A2) 


Byte 

1-3 

4-6 

8 

9 

10-11 

13-16 

33-36 


Data  Field 
Query  ID 
Question  Number 
Asterisk  Flag 
Always  "C" 

Set  Number 
First  LIRC 
Second  LIRC 


D-Type  Records  (See  Figure  A3) 


Byte 

1-3 

4-6 

8 

9 

10-11 

13-16 


Data  Field 
Query  ID 
Question  Number 
Asterisk  Flag 
Always  "D" 

Set  Number 
LIRC 


J-Type  Records 

Byte 

1-3 

4-6 

8 

9 

10-11 

13-16 

27 


(See  Figure  A4) 

Data  Field 
Query  ID 
Question  Number 
Asterisk  Flag 
Always  "J" 

Set  Number 
LIRC 

Parallel  Indicator,  P for  Parallel  LIRCs. 
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A-Type  Records  (See  Figure  A1 ) 


Bytes 

Data  Field 

1-3 

Query  ID 

4-6 

Question  - Number 

9 

Always  "A" 

10-11 

01  for  first  question  of  a merge 
00  for  last  question  of  a merge 

Format  of  database  records  is  determined  by  the  contents  of 
LIRC-FINDER-TABLE.  All  LIRCs  are  identified  with  a starting  location, 
length,  line  count,  and  number  of  occurrences. 

A. 7. 5 STORAGE  REQUIREMENTS 

Program  (less  library  modules)  occupies  42,000  bytes  on  UNIVAC 
Series  70/45. 

A. 7. 6 PROCESSING  DESCRIPTION  (Refer  to  ADSFACE  Flowchart,  page  145) 

Processing  within  ADSFACE  is  conceptually  divided  into  three 
main  areas.  Initial  processing  is  devoted  to  reading  in  the  constraints 
for  a question  along  with  the  C,D,  and  J records  indicating  the  output 
LIRCs  needed.  After  the  constraint  and  J-Record  tables  are  built,  the 
Hit  File  is  read  and  records  are  retrieved  from  the  data  base.  Fields 
are  then  extracted  from  the  database  record  as  indicated  by  entries  in 
the  J-Table.  Response  records  are  created  and  passed  one  at  a time  to 
ECM/RCM. 

Building  of  constraint  and  J-Record  tables  occurs  one  question 
at  a time.  In  the  case  of  merged  questions,  all  questions  being  merged 
are  treated  as  a unit.  The  constraint  table  is  built  up  by  storing 
each  input  record  of  the  question  including  A,  C,  D and  L-Z  type  records 
in  a table  containing  the  input  in  card  image  format.  When  SHRM  process- 
■ing  is  included  in  the  ADS  Module,  this  procedure  is  somewhat  more 
elaborate  as  will  be  described  with  the  relevant  PCP. 
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The  J-Table  is  built  up  from  C,D,  and  J type  records.  J type 
records  are  entered  as  they  occur.  Processing  of  C and  D type  records 
is  delayed.  After  all  constraint  file  records  for  the  question  have 
been  made,  a scan  of  the  J-table  is  made.  A test  for  LIRC  indicator 
of  "ALL"  is  made.  If  it  is  found,  the  LIRC  finder  table  is  used  to 
enter  J records  for  all  LIRCs  occurring  in  the  database. 

After  the  initial  scan  is  made,  a scan  of  the  constraint  table 
is  made  to  pick  up  C and  D type  records.  Before  adding  an  entry  to 
the  J-table,  a test  is  made  to  make  sure  that  a LIRC  is  not  duplicated. 
If  the  LIRC  already  is  in  the  J-table  and  it  appears  on  a D-type  record, 
the  sort  key  of  the  J entry  is  adjusted  so  that  the  entry  will  sort  to 
the  beginning  of  the  table  and  cause  that  LIRC  to  be  output  before  all 
LIRCs  not  occurring  in  D records. 

When  the  constraint  table  scan  is  complete,  the  J-table  is 
sorted  into  the  sequence  required  for  generating  response  records. 

At  this  point  table  building  is  complete. 

When  complete  hit  resolution  has  been  performed  by  PHRM,  process- 
ing of  the  Hit  File  is  less  complex.  Processing  required  when  SHRM 
capabilities  are  included  will  be  described  with  the  PCP. 

Each  hit  record  is  read  and  a test  for  a new  question  is  made. 

If  a new  question  is  encountered,  control  returns  to  the  table  building 
logic.  Otherwise,  the  record  is  read  from  the  database  as  indicated 
by  the  key  and  record  number  in  the  hit  record.  Some  preliminary 
processing  of  the  database  record  may  be  performed  at  this  point. 

Both  NLDPADS  and  NLDLADS  process  SHARP  formatted  databases.  The  LIRC 
finder  table  supplied  is  skeletal  since  locations  of  the  fields  are 
not  fixed.  A scan  of  the  record  is  made  by  the  routine  SITUATE-SHARP- 
RECORD  to  fill  in  the  locations  of  all  fields  in  the  record. 

In  the  complete  hit  resolution  case,  response  records  can  now 
be  created.  The  first  response  record  is  always  for  LIRC  0000,  the 
record  key.  This  key  is  taken  from  the  hit  file  record  since  the 
hashed  key  is  not  stored  in  the  database.  The  variable  RETURN-ADDRESS 
is  used  to  indicate  where  to  go  after  return  to  ECM  and  its  subsequent 
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call  of  the  ADS  module.  RETURN-ADDRESS  will  be  set  to  4 causing  control 
to  go  to  TEST-FOR-REPEATORS  where  the  response  records  for  this  database 
record  are  created. 

Response  records  are  created  by  extracting  the  LIRCs  in  order 
from  the  J-table.  If  no  line-count  is  indicated  in  the  hit  file  record, 
all  LIRCs  in  the  J-table  are  extracted  in  order.  If  one  of  these  LIRCs 
occurs  repeatedly,  all  occurrences  in  the  record  are  extracted  and  placed 
one  at  a time  in  response  records.  If  a line  count  is  indicated,  the 
occurrences  corresponding  to  that  line  count  for  parallel  LIRCs  are 
retrieved  on  the  first  pass  through  the  J-table.  For  non-parallel  LIRCs, 
all  occurrences  are  retrieved.  On  the  second  and  subsequent  passes 
through  the  J-table  for  a database  record,  only  those  occurrences  cor- 
responding to  the  new  line  count  are  retrieved.  Note  that  multiple  passes 
through  the  J-table  can  occur  only  when  hits  occur  on  multiple  line  counts 
within  a single  database  record.  In  any  case,  after  each  pass  through 
the  J-table  control  returns  to  the  point  where  the  next  hit  file  record 
can  be  read.  Control  flow  is  somewhat  different  when  SHRM  processing 
is  included  as  will  be  described. 

Conversion  of  field  formats  to  the  standard  NAVLIS  format  occurs 
prior  to  releasing  the  response  record  to  ECM/RCM.  In  the  databases 
currently  in  use,  this  is  limited  to  converting  from  Julian  to  calendar 
date  formats. 

Earlier  documentation  describes  processing  of  sequential  databases 
by  ADS  modules.  This  facility  is  not  provided  in  the  current  modules 
and  is  not  relevant  to  the  databases  in  use  currently. 
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FOUND 
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RECHECK-HIT-INDICATOR 


CHECK-DATA-OPEN-FLAG 


READ-HIT-FILEE 


SKIP-READ-HIT-FILEE 


READ-DATA-FILE 


SITUATE 

SHARP 

RECORD 


DPSPAC  VERSION 
ONLY 


COUNT-HITS-BY-QUESTION 


ADD  I TO 
QUESTION 
COUNT  IN 
TABLE 


/FIRSTS^ 
^IME  FOR 
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BUILD-  0- 
: RECORD.  (FOR 
0000  LIRC 
OUTPUT) 
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MADE  TO  "TEST  FOR 
REPEATERS" 


i 


TEST-FOR- 
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SHRM  CHANGES  TO  ADS 


THIS  ROUTINE 
IS  COMPLETELY 
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14C| 
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FORCE-NEXT- 

RECORD 
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yes_/exceeded 
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RECORD 
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initialize 
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ENTER-CONTRAINTAB 


SET  PAR-CONST 


SET  C-INDX-2 
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TO  BEGIN  AND 
END  OF  QST 
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V NOW?  / 
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CONSTRAINTS 
\ DONE  / 


CLEAR  TBL 
OF  SATISFIED 
GROUPS 


ROUTINES  FOR 
ENTER-CONTRAINTAB 

COMPLETELY 

REPLACED 


SET  PAR-CONST- 
SW  TO 

'iipii 


SCAN- 

CONSTRAINTS 


INITIALIZE 

VARIABLES 


/ ALL 
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^ DONE  / 


/ PAR-  \ 
CONST-SW 
vMATCHED/ 


/ THIS  \ 
/roup  ALREAD 
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-g> 


NEXT-CONSTRAINT 


INCREMENT 
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INDEX 
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TITLE;  SORT  MODULE  (SM) 


A. 8 

A. 8.1  PURPOSE 

SM  uses  the  Query  Constraint  File  (QCF)  tn  create  a single 
Blocked  Data  File  (BDF)  record  for  each  question.  These  BDF  records 
contain  the  control  information  needed  by  the  Report  Generator  Module 
(RGM).  SM  also  strings  together  all  the  necessary  Response  File  (RF) 
data  for  each  hit  and  creates  a BDF  record  complete  with  the  appropriate 
sort  key.  (Should  the  amount  of  data  be  such  that  the  maximum  BDF 
record  size  is  exceeded,  then  continuation  records  are  used.)  The  above 
process  enables  the  subsequent  sorting  to  be  done  with  fewer  record 
manipulations.  SM  processes  all  hits  from  all  files  at  once. 

A. 8. 2 INPUTS 

A. 8. 2.1  SM-CONSTRAINTS 

Query  Constraint  File  (QCF)  as  it  was  reformatted  and  output 
by  the  Screening  Module  (SCRM).  File  contains  80-character  fixed  length 
records. 

A. 8. 2. 2 RESPONSE 

Response  File  (RF)  from  the  Executive  Control  Module  (ECM). 

The  RF  contains  all  the  response  data  passed  by  all  the  ADS  Interface 
Modules  to  ECM.  More  than  one  record  defines  the  data  for  a hit. 

Each  set  of  hit  data  is  headed  by  a response  record  with  a LIRC  = 0000. 
The  RF  contains  114-character  fixed  length  records  with  5 records  per 
block. 

A. 8. 3 OUTPUT 

BLOCKED-DATA  - The  Blocked-Data  File  (BDF)  records  contain  a sort 
key  and  appropriate  QCF  or  RF  information  for  all  hits  being  processed. 
BDF  contains  895-character  fixed  length  records. 


A. 8. 4 INTERMEDIATE 


SORT-FILE  - The  Sort  File  is  used  to  sort  the  BDF  before  it 
is  used  by  the  Report  Generator  Module  (RGM).  Sort  File  contains 
895-character  fixed  length  records. 


A. 8. 5 RECORD  FORMATS  - See  Figures  A1-A5,  A7,  A14-A16 
A. 8. 6 STORAGE  REQUIREMENTS 

Program  (less  library  modules)  occupies  22,000  bytes  on  UNIVAC 
Series  70/45. 

A. 8. 7 PROCESSING  DESCRIPTION  (Refer  to  SM  Flowchart,  page  175) 


A. 8. 7.1  GENERAL  DESCRIPTION 

The  Sort  Module  (SM)  begins  processing  by  reading  the  Query 
Constraint  File  (QCF)  that  was  output  by  the  Screening  Module  (SCRM). 
Whenever  a new  question*  is  encountered,  SM  checks  to  see  if  the  user 
has  requested  the  question  be  deleted  or  the  question  had  no  hits. 

In  either  case.  SM  reads  the  QCF  until  it  encounters  the  next  question. 
Then  all  the  necessary  indicators  for  the  new  question  are  reset. 

Next,  each  QCF  record  of  the  question  is  processed  according 
to  its  type  code.  Type  A records  will  be  used  to  set  the  merge  indicator. 
Type  B,  C,  and  H records  will  be  used  to  create  a control  record  on  the 
Blocked  Data  File  (BDF)  for  the  question.  Type  D records  will  be  used 
to  create  sort  LIRC  data.  After  all  QCF  records  for  the  question  have 
been  processed,  SM  checks  the  last  D LIRC  to  see  if  it  was  0000. 

If  not,  an  additional  sort  LIRC  is  created  for  the  question.  Then  the 
BDF  control  record  is  written.  The  remaining  questions  are  processed 
in  this  same  manner. 


* For  the  purposes  of  this  writing,  "question"  will  refer  to  either  a 
single,  non-merged  question,  or  a set  of  merged  questions. 
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When  all  questions  have  been  processed,  SM  creates  BDF  data 
records  for  all  the  hit  data  on  the  Response  File  (RF).  Then  all  the 
BDF  records  are  sorted  and  control  is  returned  to  the  Executive  Control 
Module  (ECM). 

A. 8. 7. 2 QCF  TYPE  CODE  PROCESSING 

(a)  A Records  - If  type  code  for  a QCF  record  is  A,  the 
merge  question  indicator  is  set  to  1 (on)  or  0 (off), 
whichever  is  appropriate. 

(b)  B,  C,  and  H records  - If  type  code  for  a QCF  record 
is  B,  C,  or  H,  data  is  moved  from  the  QCF  record  to 
the  BDF  control  record  being  created  for  the  question. 

Should  there  be  so  many  B,  C,  and  H records  for  a 
question  that  the  maximum  size  of  the  BDF  record  would 
be  exceeded,  SM  will  ignore  the  extra  records.  Only 
one  BDF  control  record  is  created  for  each  question. 

The  sort  key  of  the  control  record  will  be  the  question 
number  and  one  trailer  (8  characters)  of  low-values. 

Also,  the  C LIRCs  will  be  stored  in  a table  for 
later  use.  The  C LIRC  table  will  handle  a maximum  of 
20  entries.  If  a C record  was  not  used  in  the  creation 
of  the  BDF  control  record,  it  will  not  be  put  in  the 
C LIRC  table.  Should  there  be  more  than  20  eligible 
C LIRCs,  the  excess  will  be  ignored. 

(c)  D Records  - If  type  code  for  a QCF  record  is  D (indicating 
a sort  LIRC),  then  the  D record  information  is  moved  to 

an  entry  in  the  D data  table  in  Working-Storage.  This  table 
will  hold  21  entries,  however,  only  20  are  reserved  for 
D record  data.  The  additional  entry  is  for  LIRC  0000  if 
it  was  not  on  the  last  D record  processed  for  the  question. 

All  questions  will  sort  on  LIRC  0000  as  the  final  sort  LIRC. 
Should  more  than  20  D records  occur  for  one  question,  the 
excess  will  be  ignored. 


Before  adding  an  entry  to  the  D data  table,  SM  will 
check  that  the  last  entry  did  not  cause  the  maximum 
possible  sort  key  size  for  the  question  to  equal  or 
exceed  200.  The  maximum  possible  sort  key  size  is 
computed  by  keeping  a running  total  of  all  the  character 
count  fields  of  the  D LIRCs  for  the  question  as  they  are 
being  processed.  The  actual  maximum  sort  key  size  on 
the  UNIVAC  is  255,  but  SM  will  allow  no  more  D LIRCs 
(except  LIRC  0000)  after  a LIRC  has  caused  the  maximum 
possible  sort  key  size  to  be  200  or  greater.  Since  a 
COBOL  Sort  is  being  used,  if  the  actual  sort  key  size 
for  any  BDF  record  should  exceed  255,  the  extra  sort 
data  will  be  ignored  in  the  sort. 

A. 8. 7. 3 BLOCK  RESPONSE  DATA 

(a)  General  Description  - To  create  the  BDF  data  records, 

SM  reads  the  first  RF  record  of  a hit.  (Note:  Each 

set  of  hit  records  begins  with  a LIRC  0000  record.) 

If  the  hit  being  processed  belongs  to  a question  which 
the  user  wants  deleted,  then  the  RF  is  read  until  the 
first  record  of  a hit  for  a question  which  is  not  being 
deleted  is  encountered.  Then  SM  processes  all  the  sort 
RF  records  for  the  hit.  These  records  are  used  to  create 
the  sort  key  for  the  hit.  Next,  the  print  RF  records  on 
the  hit  are  used  to  create  the  data  trailers  for  the  BDF 
record.  After  all  the  data  for  a hit  have  been  processed, 
the  BDF  record  is  written  and  the  next  set  of  hit  data 
is  processed.  This  continues  until  an  end-of-file  is 
reached  on  the  RF, 

(b)  Process  Sort  Response  Records  - The  sort  RF  records  are 
those  records  for  which  the  sort  indicator  field  is  equal 
to  space.  To  create  the  BDF  record  sort  key  for  a hit, 
all  the  sort  RF  records  for  the  hit  are  retrieved  and 


stored  in  a sort  response  table,  This  table  will  hold 
a maximum  of  21  entries,  Should  more  than  21  entries 
occur,  the  excess  will  be  ignored.  As  each  record  is 
stored,  it  is  checked  to  see  if  it  will  also  be  used 
as  print  RF  data.  To  determine  this,  SM  checks  the 
no-print  field.  If  it  is  a space,  then  the  sort  LIRC 
is  to  be  printed.  If  not,  then  SM  determines  whether 

the  sort  LIRC  is  also  a compute  LIRC  by  searching  the 

C LIRC  table.  If  so,  then  this  sort  LIRC  will  also 

be  treated  as  a print  LIRC.  To  keep  track  of  the  sort 

LIRCs  which  are  also  print  LIRCs,  SM  stores  both  the 
index  value  from  the  sort  response  table  of  the  sort 
LIRC  and  the  LIRC  itself  in  a hold  data  table. 

After  all  the  SF  records  for  a hit  have  been 
stored,  the  sort  key  is  created.  This  is  done  in 
a Working-Storage  area  because  the  sort  key  will 
be  needed  again  if  there  are  continuation  BDF  records. 
Also,  its  size  (less  the  Question  Number  field)  will 
be  a multiple  of  eight  since  the  trailer  fields  of 
the  BOF  are  eight  characters  long  and  sort  key  data 
and  print  data  cannot  occur  in  the  same  trailer. 

The  sort  key  is  created  by  retrieving,  in  order, 
each  D LIRC  from  the  D data  table  and  matching  it 

with  a LIRC  from  the  sort  response  table.  When  a 

match  is  found,  the  data  value  from  the  sort  response 
entry  is  moved  to  the  next  characters  of  the  sort  key 
area.  Should  a match  not  be  found,  then  two  characters 
are  moved  to  the  sort  key.  These  characters  are  space 
and  low-value  for  a low  sort,  and  two  hiqh-values  for  a 
high  sort.  (Note:  If  the  maximum  data  size  for  the 

LIRC  is  one,  then  only  the  first  character  is  moved  to 
the  key.)  After  the  last  D LIRC  has  been  matched,  SM 

checks  to  see  if  the  actual  size  of  the  sort  key  for 
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the  hit  is  greater  than  the  previous  largest  key  for  any 
other  hit  (regardless  of  the  question).  If  so,  the  new 
key  size  becomes  the  largest  key.  Then  the  remaining 


characters  (if  any)  of  the  last  sort  trailer  are  low-value 
filled  and  the  sort  key  in  Working-Storage  is  moved  by 
trailers  to  the  BDF  record. 

(c)  Move  Sort  Data  - When  a match  has  been  found  in  the  sort 
response  table  for  the  D LIRC  being  processed,  the  data 
value  from  the  sort  response  entry  will  be  moved  according 
to  the  following  procedures.  First,  the  D data  entry  is 
checked  to  see  if  the  sort  is  prefix  or  partial.  If  it 
is  a prefix  sort,  the  start  indicator  is  set  to  zero  and 
the  stop  indicator  is  set  to  the  number  of  prefix  characters 
desired.  The  start  indicator  is  actually  the  initial  set- 
ting of  the  character  index  (CHAR)  used  to  move  the  sort 
response  data  value.  It  indicates  how  many  characters  are 
to  be  skipped  before  characters  are  retrieved.  The  stop 
indicator  (MOVE-STOP)  indicates  the  last  possible  position 
of  the  last  character  to  be  retrieved.  For  a partial  sort, 
the  start  indicator  is  set  to  the  number  of  characters 
skipped  before  the  partial  sort.  The  stop  indicator  equals 
the  sum  of  the  start  indicator  and  the  number  of  characters 
in  the  partial  sort.  If  the  sort  is  neither  prefix  nor 
partial,  then  the  start  indicator  is  set  to  zero  and  the  stop 
indicator  is  set  to  the  maximum  data  size. 

Next,  the  D data  entry  is  checked  for  the  type  of  sort. 

If  it  is  a low  sort,  then  the  characters  as  they  occur  in 
the  data  value  are  moved  to  the  sort  key  area.  If,  however, 
the  user  requests  a high  sort  for  the  LIRC,  each  character 
is  moved  to  the  last  position  of  a four-character  alpha- 
numeric data  item  that  is  redefined  as  a computational  (COMP) 
item.  Then  the  COMP  item  is  subtracted  from  250.  The  last 
alphanumeric  character  of  the  result  of  the  computation  is 
the  "complement"  character  of  the  original  character.  This 
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complement  character  is  moved  to  the  sort  key.  (Note;  Since 
some  LIRCs  may  be  sorted  low  and  others  high  in  the  same  key, 
this  complement  procedure  is  needed  for  the  high  sorts.) 

The  sort  data  characters  or  complement  characters  are 
moved  by  incrementing  the  character  index  until  either  the  stop 
indicator  or  the  sort  response  data  size  is  reached.  When  one 
of  these  occurs,  if  the  character  index  is  less  than  90  and 
the  sort  response  data  size  is  less  than  the  stop  indicator, 
then  a space  and  a low-value  for  a low  sort,  or  two  high-values 
for  a high-sort,  are  moved  to  the  next  sort  key  characters. 

The  moving  for  that  LIRC  is  complete.  If  the  stop  indicator 
equals  the  sort  response  data  size,  the  move  is  complete. 

If,  however,  the  character  index  is  greater  than  or  equal  to 
; 90,  but  not  equal  to  the  stop  indicator,  then  the  next  sort 

response  table  entry  is  retrieved.  If  its  LIRC  equals  the 
one  being  processed,  then  the  moving  process  is  continued 
, until  either  the  stop  indicator  or  the  end  of  the  sort  response 

value  is  reached.  Before  continuing  the  moving,  the  start 
indicator  is  set  to  zero  and  the  stop  indicator  equals  the 
value  of  the  previous  one  less  the  character  index  (before 
■ it  is  reset).  If,  however,  the  LIRCs  were  not  equal,  then 

i 

a space  and  a low-value  for  low  sort  or  two  high-values  for 

a high  sort  are  moved  to  the  next  sort  key  characters  to 

I complete  that  portion  of  the  key. 

i 

I 

i (d)  Process  Print  Responses  - After  the  sort  key  has  been  created 

j for  a hit,  the  data  to  be  printed,  or  used  in  computations, 

is  processed.  The  sort  RF  records  already  processed  for  the 
current  hit  were  in  order  sort  by  LIRC.  Therefore,  the  hold 
data  table,  which  is  a subset  of  the  sort  RF  records,  is  also 
in  LIRC  order.  The  print  RF  records  (those  for  which  the  sort 
indicator  equals  9)  are  also  in  LIRC  order  and  occur  immediately 
after  the  sort  RF  records  for  the  hit.  The  BDF  trailers  of 
data  information  are  created  in  LIRC  order  by  merging  the  LIRC 

I, 

i 
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data  from  the  hold  table  and  the  print  RF  records.  If  SM 
determines  that  the  next  entry  from  the  hold  data  table 
precedes  the  next  RF  record,  then  the  index  in  the  hold 
data  entry  is  used  to  retrieve  the  appropriate  data  from 
the  sort  response  table.  This  data  is  then  used  to  create 
the  next  data  trailers.  If,  however,  the  next  RF  record 
comes  first,  then  the  next  data  trailers  are  created  with 
the  information  from  it. 

Before  the  data  trailers  are  added  to  the  BDF  record, 

SM  computes  how  many  trailers  will  be  needed  for  the  LIRC 
being  processed.  If  all  the  trailers  for  a LIRC  will  not 
fit  on  the  current  BDF  record,  then  none  are  put  on  it. 

The  continuation  field  of  the  BDF  record  is  set,  the 
remaining  necessary  fields  are  filled  in,  and  the  record 
is  written.  Then  a continuation  record  is  set  up  using 
the  same  sort  key  with  the  next  highest  tie  breaker  character. 
The  data  trailers  for  the  current  LIRC  are  then  added  to 
the  new  record. 

After  all  hold  data  and  print  RF  records  for  a hit  have 
been  processed,  SM  determines  whether  there  are  any  trailers 
on  the  current  BDF  record.  If  not,  nothing  is  written  and 
the  processing  continues  with  the  creation  of  the  sort  key 
for  the  next  hit.  If  there  are  trailers  on  the  current  BDF 
record,  then  the  number  of  trailers  is  compared  to  the 
maximum  number  of  sort  trailers  for  the  question.  If  the 
maximum  number  of  sort  trailers  is  greater,  then  enough 
space-filled  trailers  are  added  to  the  current  BDF  record 
to  give  it  as  many  trailers  as  the  maximum  number  of  sort 
trailers  for  the  question.  The  remaining  necessary  fields 
of  the  record  are  filled  in  and  the  completed  BDF  record 
is  written.  Print  response  processing  for  the  hit  is 
complete.  SM  is  now  ready  to  process  the  next  hit. 
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A. 8. 8 CO^'MENTS  ON  SM 
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The  maximum  sort  key  size  on  the  UNIVAC  is  255  characters. 

The  sort  key  on  the  BDF  record  will  be  composed  of  the  last  six 
characters  of  the  fixed  portion  of  the  record  (question  number)  and 
a variable  number  of  eight-character  trailers.  Some  of  the  pending 
Program  Change  Proposals  use  254  as  the  maximum  key  size.  This  is 
because  255  '>'ould  create  the  possibility  of  a sort  trailer  which 
could  never  have  more  than  one  character  of  data. 

Whenever  a sort  value  for  a LIRC  is  shorter  than  the  maximum 
size  (or  not  present  at  all),  SM  adds  space,  low  value  for  low  sorts 
or  two  high-values  for  high  sorts  to  the  end  of  the  sort  value. 

The  next  sort  value  is  then  placed  immediately  after  the  low-value 
or  the  high-values.  This  process  enables  the  sort  keys  to  be  made 
compact.  Space,  low-value  was  chosen  for  the  low  sort  instead  of 
two  low-values  so  there  will  be  no  possibility  of  any  BDF  data  records 
sorting  before  the  BDF  control  record  for  the  same  question. 

When  moving  the  sort  value,  a continuation  of  the  sort  value 
could  exist  if  the  number  of  characters  moved  is  greater  or  equal  to 
90  and  less  than  the  maximum  size  of  the  field.  The  continuation 
RF  record  will  immediately  succeed  the  first  record  and  will  have  the 
same  LIRC.  The  number-of-characters  field  on  each  RF  record  will  be 
the  actual  number  of  characters  for  the  record  being  processed. 

A. 8. 9 SORT  CONTROLS 

Tne  following  sort  control  parameter  cards  have  been  used  to 
sort  the  BDF  with  the  system  sort  on  the  UNIVAC. 

SORT  FIELDS=(10,n*,l,A),F0RMAT=BI 
RECORD  LENGTH=895,TYPE=F 
INPFIL  BLKSIZE=895,INPUT=D 
OUTFIL  BLKSIZE=895,0UTPUT=D 
OPTION  PRINT 
END 

*n  is  the  sort  key  size  (LARGEST-KEY) 
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RESPONSE 

DATA 


PROCESS 

SORT 


C TABLE 


PROCESS 

PRINT 

RESPONSES 


*NOTE:  HOLD  DATA  REFERS  TO  THE  TABLE  OF  THE  SORT  LIRCS 

WHICH  WERE  SAVED  BECAUSE  THEY  ARE  ALSO  TO  BE 
USED  FOR  PRINTING  AND/OR  COTIPUTATIONS. 
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A. 9 PROGRAM  TITLE:  IMS  Interface  Module  - DLIFSIF  also  called  IMSIF 

A. 9.1  PURPOSE 

This  module  is  designed  to  be  link  edited  with  an  applications 
program  which  updates  an  Information  Management  System  (IMS)  data  base. 
As  calls  are  made  to  IMS  to  update  segments  in  the  data  base,  this 
module  will  trap  the  calls  made  by  the  applications  program  and  create 
a log  of  all  updates  to  fields  stored  in  NAVLIS  inverted  files. 

The  module  is  to  be  used  with  both  batch  applications  programs  as 
well  as  message  programs  performing  updates  on-line.  The  log  created 
can  be  read  by  the  program  IMSFOR  (Section  A. 10)  to  create  transaction 
records  compatible  with  the  SHARP  inverted  file  update  program. 

A. 9. 2 INPUTS 

Inputs  to  this  module  consist  entirely  of  standard  interface 
data  available  in  the  applications  program.  Specifically,  parameters 
of  the  call  from  the  applications  program  to  IMS  are  interrogated  after 
the  call  has  been  processed  by  IMS.  The  parameters  used  are: 

• the  argument  count  if  provided 

• the  call  function 

• the  applicable  PCB  in  IMS 

• the  segment  I-O  area  in  the  applications  program 

• all  Sesmont  Search  Arguments  (SSAs)  provided  in 
the  call 

An  additional  input  to  this  module  is  extracted  on  the  first  call. 

To  create  the  update  log,  a Program  Communication  Block  (PCB)  must  be 
provided  in  the  applications  program's  Program  Specification  Block  (PSB) 
generation.  This  PCB  is  located  by  examining  the  save  area  given  to 
the  application  program  by  IMS.  It  is  assumed  that  the  application 
program  saved  register  1 in  this  save  area.  Using  the  address  in 
register  1,  the  list  of  PCBs  passed  to  the  applications  program  is 
located.  This  list  is  scanned  for  either  a PCB  specifying .the  output 


message  queue  (used  for  message  programs)  or  the  update  log  data  base. 

The  PCB  names  are  respectively  DLMSGO  and  DLTRNLOG. 

Detail  specifications  of  the  structure  of  data  used  by  the 
applications  program  can  be  found  in  the  IMS  Applications  Programmers 
Guide  and  will  not  be  discussed  here.  The  present  module  provides  an 
interface  for  COBOL  and  Assembler  programs.  No  interface  for  PL/ I 
programs  was  provided. 

A. 9. 3 OUTPUTS 

The  output  of  this  module  can  come  in  two  forms  depending  on 
which  output  PCB  was  located.  Since  tel  processing  PCBs  must  appear 
first  in  all  PSB  generations,  the  message  queue  PCB  will  be  located 
first  and  that  mode  will  be  used  in  preference  to  the  batch  data  base. 

The  only  difference  in  format  between  the  on-line  and  batch  modes  is 
that  the  output  generated  is  inherently  variable  length  while  the 
segments  of  a data  base  are  fixed  length.  For  this  reason,  a variable 
length  segment  is  first  generated  within  the  module.  In  the  on-line 
mode  this  segment  can  be  directly  inserted  into  the  message  queue. 

In  the  batch  mode,  this  variable  length  segment  is  broken  into  56-byte 
units  and  written,  complete  with  length  code,  onto  the  data  base  until 
all  required  data  have  been  placed  in  the  data  base. 

The  IMS  access  method  used  for  the  data  base  is  the  Hierarchical 
Direct  Access  Method  (HDAM)  although  no  randomizing  is  actually  done. 

When  the  data  base  is  initialized,  a single  root  is  placed  in  the  data 
base  by  program  IMSLOAD.  Data  are  written  onto  the  data  base  by  inserting 
a dependent  segment  as  a child  to  this  single  root.  The  segment  inserted 
has  no  key  and,  as  specified  in  the  Data  Base  Description  (DBD)  generation 
will  always  be  inserted  after  segments  previously  inserted  to  the  data 
base.  In  effect,  a sequential  file  has  been  created,  except  that  full 
backup  and  recovery  facilities  of  IMS  are  provided  and  subsequent 
executions  of  data  base  update  programs  will  never  over-write  transactions 
already  logged  in  this  data  base. 


252 


A. 9.4  RECORD  FORMATS 

There  are  no  applicable  input  record  formats.  The  variable  length 
output  record  is  formatted  as  shown  in  Figure  A17. 


Byte 

Format 

Data  Field 

1-2 

Halfword  (H) 

Record  length  ‘ ’ 

3-4 

H 

Binary  zeros 

5 

Character  (C) 

Transaction  mode.  I = insert  D = delete  R 
= replace 

6-8 

C 

NAVLIS  file  identifier.  Always  NOl . 

9-10 

H 

Segment  identifier.  Always  H'l'. 

1 1 -var 

C 

Segment  key.  Variable  length  in  general. 
Now  always  13- byte  key  from  WKACROOT. 

For  each  field  the 

1 following  data  are  recorded.  Each  affected 

field 

is  concatenated  to 

form  the  rest  of  the  record. 

Format 

Data  Field 

H 

Length  of  this 

field.  This  is  the  number  of  bytes  in  the 

field  itself  not  including  this  header  data. 

H NAVLIS  LIRC  identifier  for  this  field. 

H NAVLIS  line  count  for  this  field  if  known.  Binary  zeros 

if  no  line  count  or  unknown. 

C Value  of  the  field.  In  replaces,  this  is  the  value  before 

the  replace  was  done. 

C Value  of  the  field  after  a replace  was  done.  This  is 

present  only  for  replaces  and  is  the  same  length  as  the 
first  value. 

This  record  is  inserted  directly  into  the  message  queue  if  applicable. 
Inserts  to  the  batch  data  base  are  made  in  56-byte  increments. 

A. 9. 5 STORAGE  REQUIREMENTS 

For  the  Aircraft  Engines  Accounting  data  base  of  NMCSA  (360/65) 
total  storage  required  is  2910  bytes.  In  general,  this  is  somewhat 
variable  depending  on  the  number  of  data  bases,  segments,  and  fields 
specified  when  the  module  is  generated. 
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A. 9. 6 PROCESSING  DESCRIPTION 


Processing  of  an  applications  program  begins  at  entry  point 
CBLTOLI  in  this  module.  This  entry  point  replaces  the  CBLTDLI  entry 
point  in  the  IMS  module  DFSLIOOO.  To  provide  for  expansion  to  languages 
other  than  COBOL,  logic  relating  to  interface  with  the  applications 
program  is  separated  from  the  call  processing  performed  by  this  module. 
The  language  interface  at  CBLTDLI  is  responsible  for  passing  the 
application  program's  call  to  IMS  unchanged  before  branching  to  the 
actual  processing  routine  at  DLIMSIF,  Prior  to  entry  to  DLIMSIF, 
a pointer  to  the  applications  program's  call  parameter  list  and  the 
return  address  are  placed  in  the  normal  linkage  registers. 

After  IMS  has  completed  the  requested  function,  actual  processing 
begins  here  at  DLIMSIF.  The  first  operation  performed  is  to  make  sure 
that  initialization  operations  are  completed.  On  the  first  call,  INITRTN 
is  called  to  locate  the  PCB  list  provided  by  IMS  and  initialize  appro- 
priate tables  in  this  module.  When  tables  have  been  built,  the  next 
step  is  to  determine  whether  the  PCB  supplied  by  the  applications 
program  is  to  be  processed  here.  If  the  PCB  does  not  refer  to  a data 
base  whose  updates  are  being  trapped,  no  further  processing  is  to  be 
done.  Control  returns  to  the  original  caller.  If,  on  the  other  hand, 
updates  are  to  be  trapped,  the  function  code  is  tested  and  an  appropriate 
routine  is  branched  to.  The  routines  are: 


Function 

Routine 

All  GH 

GHRTN 

ISRT 

ISRTN 

REPL 

REPLRTN 

DLET 

DLETRTN 

Other 

Return  to  Cal ler 

Processing  is  specific  to  the  function  specified.  Routine  GHRTN 
processes  all  Get-Mold  (GH)  calls.  Its  function  is  to  store  the  "before" 
images  for  later  comparison  on  updates.  Notice  that  IMS  requires  the 
user  to  first  issue  a GH  call  before  a REPL  or  DLET  can  be  performed. 
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The  GH  routine  must  cope  with: 

(1)  Invalid  Status  Indicators  returned  by  IMS.  This  includes 
segments  requested  which  do  not  exist  in  this  data  base. 

(2)  Calls  using  qualification  on  multiple  levels  within  the 
data  base  using  multiple  SSAs. 

(3)  Calls  requesting  that  segments  from  more  than  one  level 
in  the  data  base  be  concatenated  in  the  user's  I-O  area. 

Status  codes  are  tested  first.  Only  if  the  code  indicates  that  data 
could  have  been  returned  to  the  applications  progr-m  will  processing 
continue  here.  The  level  code  in  the  PCB  will  be  used  to  determine 
exactly  which  segments  were  actually  returned.  After  some  initializa- 
tion, processing  proceeds  SSA  by  SSA. 

The  segment  entry  is  located  in  the  tables  generated  for  this 
database  using  the  segment  name  specified  in  the  SSA.  If  command  codes 
in  the  SSA  indicate  that  data  were  placed  in  the  user's  I-O  area  for 
this  segment,  the  fields  of  interest  are  extracted  from  the  I-O  area 
and  placed  in  a hold  area  in  this  module.  Concatenations  caused  by 
path  calls  (command  code  D)  can  be  processed  by  adjusting  a pointer 
to  the  user's  I-O  area  as  SSAs  are  processed.  The  processing  of  SSAs 
is  terminated  either  by  an  SSA  which  is  not  found  in  this  data  base's 
table  entry  or  by  one  whose  level  exceeds  the  maximum  level  returned 
to  the  user  as  indicated  by  the  level  code  in  the  PCB. 

Since  similar  operations  of  extracting  selected  fields  from  the 
users  I-O  area  are  used  for  GET  HOLD  and  REPLACE  calls,  a common  routine 
MVSEGFIO  is  used  both  in  GHRTN  and  ISRTN. 

Processing  of  inserts  is  similar  to  that  described  for  GET  HOLD 
calls.  The  primary  difference  is  that,  as  fields  are  extracted  from 
the  user's  I-O  area,  the  data  are  placed  directly  in  an  output  record 
area  rather  than  in  a hold  area.  A second  difference  is  in  the  interpre- 
tation of  command  code  D in  the  SSA.  In  a GET  call,  the  D code  is  used 
for  every  segment  to  be  retrieved.  On  an  INSERT  call,  the  D code  indi- 
cates that  this  and  all  lower  level  segments  in  the  list  of  SSA's  are 
concatenated  in  the  user's  I-O  area. 
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Processing  of  REPLACE  calls  is  done  by  REPLRTN.  The  first  test 
for  other  calls  is  to  see  whether  IMS  returned  a successful  status  code. 

If  so,  processing  proceeds  SSA  by  SSA.  Each  SSA  is  tested  for  an  N 
command  code  indicating  that  data  for  the  segment  are  present  in  the 
user's  I-O  area  but  are  not  to  be  processed  by  the  replace  operation. 
Whenever  an  N is  found,  the  hold  area  is  searched  for  an  indication 
that  data  have  been  stored  for  the  segment.  Since  no  data  were  changed 
by  the  call  in  this  case,  no  comparison  is  made  here  for  changed  fields 
for  the  segment  named  in  the  SSA.  After  this  test  is  made,  routine 
MVSEGFHA  will  be  used  to  compare  fields  in  the  user's  I-O  area  with 
those  stored  in  the  hold  area  by  the  previous  GET  HOLD  call.  Entries 
are  placed  in  the  output  record  for  changed  fields  only. 

Processing  of  deletes  is  done  by  routine  DLETRTN.  It  is  similar 
to  REPLACE  call  processing.  The  first  SSA  provided  by  the  caller  indicates 
the  lowest  level  segment  to  be  deleted.  Segments  of  a higher  level 
stored  in  the  hold  area  from  the  preceding  GET  HOLD  call  are  not  processed 
for  deletes.  Segments  which  were  deleted  are  processed  by  routine 
MVSEGFHA  which  creates  the  output  record  reflecting  the  fields  previously 
contained  in  the  deleted  segments. 

Initialization  is  performed  by  routine  INITRTN.  The  first  task 
performed  is  the  location  of  the  original  PCB  list  through  save  areas. 

It  is  assumed  that  the  highest  level  save  area  belongs  to  the  region 
controller.  Hence  the  next  save  area  in  the  chain  contains  registers 
as  passed  to  the  applications  program.  The  highest  level  save  area  is 
located  by  an  EXTRACT  macro  which  returns  the  location  of  a field  of  PCB. 

A fixed  off-set  from  this  is  the  pointer  to  the  highest  level  save  area. 
Once  the  PCB  list  is  located  through  the  register  1 value,  a scan  is 
made  of  the  entries.  Each  data  base  specified  in  a PCB  is  inspected  to 
see  whether  it  is  to  be  processed  by  this  routine.  If  it  is,  an  entry 
is  made  in  the  PCB  table  here,  and  hold  area  space  is  allocated  for 
storage  of  fields  returned  on  GET  HOLD  calls.  A test  is  also  made  for 
the  output  message  queue  or  data  base  PCB's.  The  first  one  found  is 
saved  for  later  use  in  calls  to  actually  insert  the  logged  data  through 
IMS. 
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^ ■'  Change  data  are  logged  by  the  routine  PUTOUT.  If  the  output 

^ message  queue  is  being  used,  an  INSERT  call  is  made  to  IMS  (using  entry 

point  DFSASM).  If  an  output  data  base  is  used,  56-byte  segments  are 
inserted  until  all  change  data  have  been  written. 
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MACROS 


The  following  MACROS  have  been  provided  to  generate  the  block  describing 
segments  and  fields  of  interest  to  NAVLIS,  Keyword  parameters  are  also 


listed. 

DEFDBD 

- 

Defines  a DBD,  This  must  be  coded  prior  to  other 
definitions. 

NAME 

- 

Name  of  DBD 

SEGl 

- 

Primary  segment  for  update  log. 

SEG2 

- 

Secondary  segment  for  update  log.  This  will  be  a 
dependent  of  SEGl . 

DEFSEG 

“ 

This  must  be  coded  prior  to  any  field  definitions. 
If  a lower  level  segment  is  defined,  a complete 
hierarchial  sequence. 

NAME 

- 

Segment  name  - omit  if  a continuation. 

LEVEL 

- 

Level  of  segment.  This  must  be  two  digits. 
Default  is  01 . 

FILE 

- 

NAVLIS  file  ID 

ID 

- 

NAVLIS  Segment  Identifier;  default  is  1. 

lOLEN 

Length  of  I-O  area  occupied  by  this  segment. 
Default  is  0.  This  must  be  correct  for 
processing  of  path  calls.  Consider  omitting 
it  on  continuation  definitions. 

KFBLEN 

- 

Length  of  key  data  to  be  taken  from  PCB  key  feedback 
area.  Default  is  0. 

KEYPOS 

- 

Starting  position  in  I-O  area  from  which  key  data 
are  to  be  taken. 

KEYLEN 

- 

Length  of  key  data  in  I-O  area 

ISRT 

- 

Yes  or  No.  Code  No  if  inserts  are  not  to  be  logged. 
Default  is  Yes. 

DLET 

- 

Yes  or  No.  Code  No  if  deletes  are  not  to  be  logged. 
Default  is  Yes. 
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REPL 

CONT 


DEFFLD 

LIRC 

LINECT 

START 

LENGTH 

DBDEND 


Yes  or  No.  Code  No  if  replaces  are  not  to  be  logged. 
Default  is  Yes. 


Yes  or  No.  Code  Yes  if  this  segment  defines  the  same 
segment  as  the  one  previously  defined.  This  is  used 
if  new  parameters  are  to  be  supplied  for  the  fields 
defined  for  this  segment,  particularly  File  and  ID 
in  logical  data  bases. 


Defines  a field 

NAVLIS  LIRC  for  this  field 

Line  count  of  the  field.  Default  is  0. 

Starting  position  in  I-O  area. 

Length  of  this  field. 

End  of  definitions.  This  must  be  the  last  MACRO  coded. 


For  generation  of  the  interface  module,  a MACRO  is  provided: 
IMSIF  - Generates  interface  routine. 


DLIMSIF 


First 


Time 


Call 

Initializa- 
tion Routine 


DLINITCM 


Determine 
Number  of 
Call 

Parameters 


Only  Part  of  This 
Processing  is  Done 
Before  Testing 
PCB  Table. 


DLPCBADF 


This  PCS' 
Tn  Table^ 


SRCHPCBT 


Get  Hold 

Processing 

Routine 


DLCNTDET 


Function' 


Insert 

Processing 

Routine 


Other 


Replace 

Processing 

Routine 


Return 


To  To 
. Return 


1 


Delete 

Processing 

Routine 
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/ Table 
Entry  = 
\ PCB 


Save  Locatior 
Set  Found 
Return  Code 


stable 

Entry 

vEmpty 


SPTNOTFOUND 

I — 

Save  Locatior. 

Set  not 
Found 

Return  Code 


Add  Rehash 
Increment 
To  Current 
Offset 


SPTRETRN 


Return  to 
Caller 
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GHRTN 


Go  To 
Return 


Other 


GHSTAKOK 


Set  Mode 
Flag  to 
Get  (G) 


Point  to 
DBD  Entry  & 
First  Seg 
Entry 


Zero  Out 
Segment 
Count  In 
Hold  Area 


Calculate 
Number  of 
SSAS  In 
Call 


Get  Seg 
Name  From 
PCD 


X Is  \ 
SSA  Count 
\ Zero  / 


Go  To 
Return 


GHSSASUP 


Loop 

Through 

SSAS 

Provided 


GHTSTSSA 


Call  COMCDTS 
To  Test  For 
D Command 
Code  In  SSA 


GHNXTSSA 


Point  To 
Next  SSA 


Found 


GHINPATH 


Get  Seg 
Name  From 
SSA 


All 

SSA  Done 


Call  MVSEGFIO 
(Move  Seg 
From  ID  Area) 


Seg 

In  Table 


Go  To  Return 


ISSTATOK  Taa,GE,II 


Set  Mode 
Flag  To 
"Insert" 


Point  to  DBD 
Entry  And 
First  Seg 
Entry 


Compute 
Number  of 
SSAS  Provided 


Point  To 

Next 

SSA 


Call 

COMCDTST 
To  Test  For 
"D"  Code 


Decrement 
Count  of 
Remaining 
SSAS 


Command 


REPLRTN 


^Test-v 

'PCB  Status^.  Ocher 


Go  To 
ReCurn 


RPSTATOK 


RPTSTSSA 


Set  Mode 
Flag  To 
"Replace"  (R) 


Compute 
Number  of 
SSAS  Providec 


X //  0f\ 

SSAS  Zero 


/Loop 

Through 

SSAS 

\Provided 


Call 

COMCDTST 
To  Test  For 
"N"  Code 

I 

/”N"\ 
^^Command'x 
Code 
F ound/^ 


Point  To 
Next  SSA 
In  Call 
List 


X All  \ 
SSAS  Done 


RPTSTHSG 


Loop  ' 
Through 
Seg  In 
Hold  Area, 


Match  No 
With  SSA  > 


RPNXTHSG 

Yes 


Set  Flag 
On  Hold 
Area  Pointer 


/All\ 
SSA  In 
Hold 
\Done 


Call  MVSEGFHA 
(Move  Seg 
From  Hold 
Area) 


r Go  To 
V Return 


DLETRTN 


DLSTATOK 


DLTSTSNM 


DLHSFCOM 


Point  To 
Next  Seg 
Entry 


MINOTFND 


!Set  Not 
Found 
Return 
Code. 


MISEGFND 


Get  Gount 
And  Location 
Of  Field 
Entries 


MIRETRN 


No  Fields 


Move  Set 
Header  To 
Output  Rec 


Move  Key 
From  KFB 
In  PCB  And 
10  Area 


18c 


MVSEGFliA 


278 


COMCDTST 


Loop  Thru 
SSA  Char 
After  Seg 
Name 


CCDEXSSA 


Found 


COMCDFND 


Set  Found 

Return 

Code 


:OMCODE 

Found 


Return  To 
Caller 


Limit 

Reached 


Return  To 
Caller  - 
Code  Not 
Found 


PUTOUT 


Save  Work 
Registers 


Compute 
Record 
Length  And 
Store  It 


Move  Seg 
Name  To 
SSA  (From 
DB  Table) 


Loop  Thru\ 
Each  Output 
Segment  . 
.Needed  / 


Call  IMS 
To  Insert 
Or  Purge 


Status 

OK 


Abend 

With 

Dump 


Restore 

Work 

Registers 


Ad  j us  t 

Pointers  For 
Next  DB 
Seg 


'Return  To 
Caller 


A. 10  TITLE;  IMS  FORMAT  UPDATES  MODULE  - IMSFOR  also  called  DLIMSFOR 


A. 10.1  PURPOSE 

This  module  is  used  to  convert  the  updates  trapped  by  IMSIF  to 
a format  acceptable  to  the  Inverted  File  Update  Program.  This  module 
can  be  run  in  either  a batch-message  region  or  a batch-only  region  of 
IMS.  In  a batch-message  region,  input  can  be  taken  either  from  a message 
queue  containing  the  updates  or  from  a data  base.  Some  operational 
impact  may  be  noticed  when  using  a data  base  as  the  input  source  since 
exclusive  access  to  the  data  base  is  required. 

A. 10. 2 INPUTS 

Input  to  this  module  can  be  from  two  sources,  either  a data  base 
or  a message  queue.  The  record  formats  are  essentially  identical. 
Segments  from  the  message  queue  are  formatted  as  follows: 


Byte 

Format 

Data  Field 

1-2 

H 

Record  length 

3-4 

H 

Reserved  for  IMS 

5 

C 

Transaction  code;  I = Insert, 
D = Delete,  R = Replace 

6-8 

C 

NAVLIS  file  identifier 

9-10 

H 

Segment  identifier 

11-Var 

C 

Segment  key 

Remainder  of  the  record  is  devoted  to  field  entries.  These  entries  are 
concatenated  after  the  segment  key.  Each  field  entry  consists  of: 


Byte 

Format 

Contents 

1-2 

H 

Length  of  field  data 

3-4 

H 

LIRC  of  field 

5-6 

H 

Line  count  of  field  if 
known,  otherwise  zero 

7-Var 

C 

Value  of  field.  In  REPLACE  calls 
this  is  value  before  replace  attempted. 

Var 

C 

Value  of  field  - REPLACE  calls  only. 
Value  after  replace  completed. 
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Segments  in  the  data  base  are  created  by  breaking  this  record  into 
56-byte  units  and  inserting  as  many  56-byte  segments  as  required  to 
hold  the  data.  The  length  code  is  used  to  tell  how  much  data  to 
process  in  the  last  segment. 

A. 10. 3 OUTPUT 


^ i 


Output  of  this  module  is  designed  to  be  used  by  the  standard 
SHARP  Inverted  File  update  program.  The  output  here  must  be  sorted 


to  meet  the 

requirements 

of  SHARP.  Records  created  to  update  the 

Inverted  File  are: 

Byte 

Format 

Data  Field 

i 

C 

File  ID  - not  used  by  SHARP 

4-7 

C 

Not  used 

8-11 

C 

LIRG 

( 12 

C 

Not  used 

! 

i 

C 

Action  Code 

Space  = add  to  Inverted  File 
1 = delete  from  Inverted  File 

14 

C 

Not  used 

15-23 

C 

Hashed  key  of  record 

i 24-35 

C 

Not  used 

36-38 

4 

C 

Line  count 

j 39-88 

C 

Value  of  the  field 

j An  additional  function  of  this  module  is  to  add  records  to  the  Record 

j Descriptor  File  for  new  records  added  to  the  data  base.  These  records 

) contain: 

t 

I 

i 

1 Byte 

1 

Format 

Data  Field 

i 1 

C 

Delete  byte  - not  used 

i 2-10 

C 

Hash  key  of  the  data  base  record  i 

1 11-40 

C 

Actual  key  of  the  data  base  record  | 

41-46 

C 

Record  number  of  data  base  record  - not  used 

1 
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j 


1 

\ 

i 
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A. 10.4  RECORD  FORMATS:  See  Figure  A18  ^ 

A. 10. 5 STORAGE  REQUIREMENTS 

Program  occupies  approximately  11,000  bytes  on  IBM  360/65, 

i 

A. 10. 6 PROCESSING  DESCRIPTION  (Refer  to  IMSFOR  Flowchart,  page  220) 

■i 

The  first  major  decision  made  in  this  module  is  to  determine  the  ! 

source  of  the  input,  i.e.,  message  queue  or  data  base.  If  input  is  from  | 

the  data  base,  the  initial  root  segment  is  retrieved  since  all  transaction 
data  are  stored  as  dependent  segments.  Message  queue  retrieval  does  not 
require  prior  positioning.  j 

Each  input  record  is  processed  by  retrieving  a complete  input  | 

record  even  if  it  spans  multiple  segments.  If  the  action  indicated  is 
an  INSERT,  a new  record  must  be  added  to  the  Record  Description  File; 
otherwise  the  existing  record  must  be  found  so  that  the  correct  hash 
key  can  be  determined.  Both  inserts  and  deletes  require  a transaction 
for  the  "0000"  LIRC;  these  are  "add"  and  "delete"  respectively.  All 
fields  in  the  input  record  are  then  processed. 

Processing  of  each  field  consists  of  moving  File  ID,  LIRC,  Line 
Count,  Hash  Key,  and  Field  Value  to  the  output  record.  Inserts  have  an 
action  code  of  "add";  deletes  and  replaces  have  "delete".  A second 
record  is  generated  for  a replace  to  add  the  new  field  value. 

Processing  used  in  adding  new  records  to  the  Record  Descriptor 
File  and  in  locating  existing  ones  is  similar.  In  both  cases,  an 
initial  hash  key  is  determined  using  the  same  logic  as  INVERTAE.* 

Using  the  sequence  of  tie  breaker  characters  that  were  used  in  building 

the  file,  it  is  searched  until  either  the  desired  record  is  found  or 

the  record  is  found  to  be  missing.  It  is  assumed  that  no  records  are 

deleted  - at  least  none  are  here.  The  expected  result,  when  attempting 

to  locate  an  existing  record,  is  that  the  scan  will  terminate  with  the  -i 

desired  record.  When  a new  record  is  to  be  added,  the  first  missing 

■ ^ 

hash  key  is  assigned  to  the  new  record.  If  an  error  is  detected,  a \ 

message  is  displayed,  corrective  action  taken,  and  processing  continues.  i 

* Program  used  to  create  the  Inverted  Master  Files  for  the  Aircraft 
Engines  Accounting  Data  Base.  ! 
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PROCESS-INPUT 


f Section 
^ Exit 
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FIND-KEY- IN-RDF  SECTION 
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SCAN  DESC  FILE 


^ Section  ^ 


APPENDIX  B 


CINCLANTFLT  NAVLIS  APPLICATION  CASE  STUDY 


I.  INTRODUCTION 

This  report  addresses  the  use  of  query  sets  in  conjunction  with 
inverted  logistics  data  for  the  sharing  (communication)  of  Navy  logis- 
tics information.  The  base  consists  of  ship  scheduling  and  funding 
information.  The  report  is  presented  to  indicate  the  applicability 
of  the  NAVLIS  concept  to  today's  fleet  problems.  The  application 
was  developed  with  the  assistance  of  the  CINCLANTFLT  Maintenance  and 
Material  Readiness  Division,  Code  NFM3A. 


II,  BACKGROUND 


Much  of  the  early  NAVLIS  effort  was  concerned  with  an  attempt  to 
classify  logistics  information,  synonym  resolution,  and  dictionary  schema. 
The  LIRC  code  assignment  problem  had  been  studied. 

After  the  project  had  been  transferred  to  DTNSRDC,  specifications 
for  a standardized  set  of  access  routines  (query  modules)  were  written. 
These  specifications  were  an  adaptation  of  the  already  existing  SHARP 
query  modules.  The  NAVLIS  query  modules  interfaced  with  network  communi- 
cations software  for  distributed  system  access.  They  also  interfaced 
with  the  native  computer  system  in  order  to  access  and  retrieve  the  data 
from  the  base  (files).  Access  is  gained  by  means  of  an  inverted  file 
which  was  built  and  maintained  in  conjunction  with  the  native  system. 

Although  a NAVLIS  users  group  was  formed,  the  group  was  never 
instrumental  in  formulating  requirements  for  a NAVLIS.  It  did  ask 
questions.  Because  of  the  lack  of  direct  user  involvement  in  NAVLIS, 
the  project  manager  with  the  assistance  of  his  staff  surveyed  Fleet 
Maintenance  at  Norfolk  and  concluded  that  it  would  be  a good  logistics 
area  in  which  to  involve  a user  with  NAVLIS. 

A meeting  between  NAVLIS,  3M,  and  Fleet  Maintenance  personnel  was 
held  in  Norfolk.  3M  personnel  maintained  they  had  no  need  of  NAVLIS 
involvement  but  the  Fleet  Maintenance  user  pointed  out  that  the  3M 
system  is  lacking  certain  types  of  financial  information  which  can  be 
used  in  decision  making. 

NAVLIS  personnel  returned  to  DTNSRDC  and  built  a small  data  base 
using  the  SHARP  data  base  management  system  which  could  be  queried  from 
a terminal.  (No  computer  instructions  were  written).  A return  visit 
was  made  to  Norfolk  and  the  user,  during  a single  1-1/2  hour  interactive 
terminal  session,  defined  his  information  requirement  and  obtained  the 
computer's  answer  to  his  questions.  Fleet  Maintenance  Division  then,  and 
greatly  as  a result  of  this  experience  agreed  to  cooperate  in  the  NAVLIS 
research  effort. 

NAVLIS  personnel  again  returned  to  Norfolk  and  performed  a formal 
requirements  analysis  based  on  the  user's  assessment  of  his  information 
access  need.  After  completion  of  the  requirements  analysis,  the  analyst 
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returned  to  DTNSRDC  and  designed  the  data  base  architecture.  The  primary 
considerations  in  the  mind  of  the  analyst  during  the  architectural  design 
period  were: 

• The  design  would  be  open  ended.  No  restrictions  on  the 
ability  to  add  any  type  of  logistics  data  to  the  base. 

• No  attempt  would  be  made  to  physically  account  for  data 
in  the  system.  That  function  would  be  fully  delegated 
to  the  SHARP  data  base  management  system. 

• The  design  would  be  such  that  it  would  appear  to  the 
user  that  he  was  accessing  distributed  data  base  files. 

The  architecture  permitted  this  to  be  done  in  a single 
query,  thus  simulating  NAVLIS. 

• Information  would  be  time  referenced  so  that  a tracing 
capability  (pictures)  of  what  was  happening  at  a given 
time  or  during  a specified  period  of  time  could  be 
presented. 

• A high  degree  of  accuracy  was  required. 

• The  data  base  would  not  be  classified. 

• Accurate  record  keeping  would  be  facilitated. 

These  design  requirements  were  achieved  through  the  following  specific 
design  features: 

• The  use  of  separate  sets  of  descriptions  within  one 
description  for  different  classes  (files)  of  data  so 
that  additional  sets  can  be  added  and/or  incorporated 
at  will  without  making  any  changes  to  the  existing 
structure.  Any  type  of  data  such  as  CASREP  data  can 
be  added  without  disturbing  the  work  done  to  date. 

• The  use  "as-of-dates"  to  stamp  alj_  time-based  information. 

The  funding  of  a ship  is  an  event.  The  dictionary  in  a 
sense  is  not. 


I 

1 

i 

! 

t 

\ 

4 

t 
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• The  use  of  redundancy  to  achieve  accuracy.  Individual 
accounting  records  contain  balanced  fields. 

• Users  can  work  any  time  in  terms  of  ship  names,  UIC 
codes,  or  Hull  designations.  They  may  be  mixed  in 
the  query  in  any  combination  desired. 

• The  information  content  of  the  base  can  be  accessed 
on  the  basis  of  Navy  organization  qualifiers. 

• The  individual  who  is  considered  the  "owner"  is  always 
available  to  query. 

• There  is  no  fuel  information  of  any  type  in  the  base, 
no  projected  force  levels,  no  information  about  ship 
activation  and  de-activation. 

After  the  design  was  completed  and  the  data  base  was  built  suffi- 
ciently to  prove  the  design,  a meeting  took  place  in  Norfolk.  About  two 
weeks  later  Fleet  Maintenance  personnel  visited  DTNSRDC,  operated  the 
system,  and  obtained  the  answers  to  questions. 

III.  OBJECTIVE 

The  NAVLIS  objective  in  attacking  ship  scheduling  and  maintenance 
problems  was  two  fold; 

a.  Research  the  information  systems  problem  from  the 
standpoint  of  on-line  distributed  data  base  archi- 
tecture and  access. 

b.  Apply  the  NAVLIS  concept  by  doing  something  useful 
for  the  fleet  using  a scheme  which  involved  the 
NAVLIS  Pilot  model . 

It  was  recognized  that  resource  management  would  be  the  most  difficult 
field  in  which  to  apply  NAVLIS  because  schedules  and  money  are  involved. 
It  was  also  recognized  where  the  pay  off  would  be.  Resource  management 
necessitates  the  sharing  (communication)  of  information. 
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The  strategy  used  to  meet  the  objective  was  to  do  what  the  fleet 
maintenance  people  wanted  done,  from  a user's  standpoint.  Once  the 
data  base,  which  was  solely  for  operational  purposes  on  behalf  of  fleet 
maintenance,  had  been  built,  it  would  be  moved  to  DPSCLANT  where  it 
could  be  queried  without  communication  costs  under  SHARP  or  the  NAVLIS 
Pilot  Model  installed  locally  at  Norfolk.  This  would  help  DPSCLANT  and 
using  the  NAVLIS  tie-in  between  DPSCLANT  and  NMCSA,  we  would  migrate  the 
user  from  having  the  questions  answered  from  the  local  base  to  having 
the  same  questions  answered  from  the  distributed  files.  Once  this  was 
achieved,  the  user  would  be  in  a position  to  validate  the  NAVLIS  concept. 
After  the  model  was  in  use,  the  Navy  could  decide  the  next  step. 

IV.  APPLICATION 

A.  Information  Content  of  the  Base  (See  Figure  B1  for  SHARP 

defini tions. ) 

The  data  base  consists  of  approximately  4,000  records.  The  histor- 
ical records  in  the  data  base  include: 

• overhaul  start  date 

• end  date 

• type  of  overhaul 

• yard 

• home  port 

• commission  date 

• overhaul  duration 

• overhaul  interval 

• man  days  expended  including  new  construction 

• ship  identification 

The  data  dates  back  to  approximately  1962. 

The  apportionment  records  in  the  base  include  the  73,  74,  75,  and 
76  fiscal  years.  The  data  include  ship,  start  date,  end-date  man-day 
cost,  material  dollars,  and  unit  cost. 

The  funding  records  for  ship  overhaul  include  the  funding  information 
for  each  ship  for  each  month  for  the  12-month  75  fiscal  year  and  July  and 
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August  of  fiscal  76,  Information  includes: 


1. 

2. 

3. 

4. 

5. 


ship  identification 
start  date 
end  date 
yard 

complete  set  of  funding  information  for  active  and 
reserve  ships  including: 

a.  carry  over  requirements 

b.  current  fiscal  year 

c.  selected  restricted  availability 

d.  advanced  funding  requirements 


The  data  base  also  includes  the  overhaul  standards  for  each  class  of 
ship,  except  those  which  are  classified.  The  classified  standards  are 
not  in  the  base. 

The  data  base  also  includes  a projected  ship  overhaul  schedule  out 
to  1981.  This  is  very  hypothetical  and  is  not  updated  to  reflect  the 
current  situation.  It  was  included  in  the  design  as  a tool  for  fleet 
maintenance  operations  use  if  and  when  "what  if"  questions  are  asked. 
This  requires  an  algorithm.  (See  Figure  B-1).  This  portion  of  the  base 
consists  of  about  300  records. 

To  summarize,  the  data  base  consists  of  a set  of  duration  and  inter- 
val standards,  a hypothetical  (5-year  forward)  schedule,  apportionment, 
advanced  funding,  current  fiscal  year,  carry  over  funding  activity,  and 
ship  overhaul  history,  all  time  stamped. 


10  3ASE2 

OlftCOIJ;  MAXSIZc.  = 9!CHAyS  1/»!NJM£RIC  OR  VAlU£:>  = INTRO,  lA8£L  , CA 

OEFIN,  INFOR,  VAlUS;  C^ARS  a/aj  NOMcRIC  OR  iPAGES?  INVERT  C8 

ItNAVV;  RAXSIZE=15!  INVERT  lA 

2IPR0O/0ATE5  SIZ£=b;  CHARS  1/25  VALUE=Z55  SHARS  3/A5  RAN5E*«l/125  2A 

CHARS  >/65  RANG:  = n/31S  INVERT  20 

31HULL5  HAXSIZE=65  INVERT  3A 

l*)SHIP;  HAXSIZE  = 185  INVERT  4A 

5IUIC5  MAXSIZt=55  INTtGiR;  INVERT  5A 

6ICMSN0AT:.;  HAXSIZi  = 65  CHARS  1/25  RANGE  = 4J/d25  CHARS  3/^5  RANGE  = 01/125  6A 

CHARS  6/65  RANGt=:i/315  INVERT  63 

7»TVC0M;  MAXbIZc.  = i;  INTEGl?;  invert  7A 

8)ASOFOATE;  HAXiIZE=b5  CHARS  1/25  RANG£=5:/325  CHaRS3/45  RANGE=01/12;  8A 

CHARS  a/65  RANi,L  = Cl/3l  5 INVERT  88 

9»COR5  MAXSIZt=155  ALPHA35  INVERT  9A 

lOIOUaATNS  MAXSIZt=35  RcAc5  OEC  15  INVERT  ICA 

llUNTRVu;  HAXSIZil=35  RE1..5  3EC  15  INVERT  llA 

12)  STARTDATt5  MAXSIZE=65  CHARS  1/ 25  RANG£=5a/825  CHARS  3/45  12A 

RANGt:  = 01/125  CHmRS  a/b  5 RANG£  = J1/315  INVERT  128 

13) ENDATE5  MAXSIZE=6S  -HARS  l/?5  RANGE=5J/825  CHARS  3/45  13A 

RANGi=Cl/i25  ^HARS  a/65  RANG£=0l/315  INVERT  133 

14) FCLTT5  HAXSIZc.  = 55  INVERT  14A 

15>PVKTRFNia5  HAXSIZt=a5  INT£SiR5  INVERT  15A 

16) CM0R05  MAXSIZi=55  INTEGERS  INVERT  IbA 

17) CNTTRPlN5  MAXSiZEijS  INTEG.R!  INVERT  17A 

18) CNIPLNT0T 5 MAXSIZE=55  INTEGER;  Inv:RT  18A 

19) TOTFN05  HAXSIZ£=55  INTEGERS  INVERT  19A 

20ICNTYRFND5  hAXSIZ_=3S  INTEGERS  INVERT  20A 

2DESTCNTTKQTS  HAXSIZ^=a5  INTEGERS  INSERT  21A 

22) fcSr0VHL5  HAXSIZi=55  INTcGERS  INVERT  22A 

23) PErCNTOVHL5  MAXSIZc=^6:  InT;.GER5  INVERT  23A 

24) 80GTLJATS5  MAXSIZi  = 6:  IMEGtRS  INVERT  24A 

25) BOGTLHNr5  MAXaIZt=55  INTEGERS  INVERT  254 

26) 30GTMiNnY5  HAXaIZt  = aS  INTEGERS  INVERT  26A 

27)  eOGTUCGsT  5 HAXSIZ:.  = >5  INTEGERS  INVERT  27A 

28) ACTlDAYS5  HAXilZ>=Zt  iNT_G£RS  INVERT  28A 

29) ACTLMNY;  MAXaIZE=a5  INTEGERS  INVERT  29A 

Ju)ACTMMNY5  HAxSIZ(.  = a5  INT-GER5  INVERT  30A 

3DACTUCOST5  HAXSIZE^aS  INTcGERS  INVERT  31A 

32) H0Ht.P0i<T  5 MAXSIZc=125  INVERT  32A 

33) FNcmCTVTY5  MAXSIZc=6S  INVERT  33A 

34) SC0ACTVTY5  MAXaIZc=65  INVERT  34A 

35)  OVHlACT VTY;  HAXaIZc=bS  INVcRt  35« 

36) 1H«CTVTY5  MAXSIZE=b5  INV.RT  36A 

37) TyPEOVHL5  nAXSIZc=oS  INVERT  37A 

38) PURCHORD5  MAXSIZ-.  = 65  INVERT  38A 

39) LINKT05  MAXSlZc  = 2C5  RE->EAT5  INVERT  39A 

4Q)NOTc5  MAXSIZE=153C  4bA 

4DASSOC5  MAXaiZc  = 95  INVENT  41A 

42) NARK5  SIZt=15  INVEkT  42A 

43) TWX5  HAXSIZc^laO:  43A 

44) lInKFH5  MAX5lZE  = 23  5 REPEAT  <,4A 

45) SHIPID5  NAXSIZE=185  REPEATS  INVERT  45A 

4b)DAT£5  HAXSIZE=bS  Ch,RS  1/25  RA  NGE  =a  C /8  2 5 CHARS  S/'*:  RANGE=31/12S  46A 

chars  a/65  RANaE=:i/3lS  REPEATS  ciNKS  kOLES  INVERT  463 

47) HONEY5  NAXSlZc=lJ5  INT^GE’!  RcPEATS  LINKS  ROLES  INVERT  47A 

48) uICIsU6ScT5  MAXSIZ^=lr5  INVERT  48A 

49) ACRONY.15  NAXSIZt=llS  INVERT  49A 

50) S£i,TION5  MAXaI2t  = 2S  AlpHAT:  INVERT  5CA 

5DINF0S  MAXSIZc=15;j  51A 

52) NAvlIS5  HAXSIZE=155  INVERT  524 

53) CIIuTSU3SET  5 MAXSIZc=la5  INVERT  534 

54) SUjScToTl5  mAXSIZE=35  INTEoERS  INVERT  54A 

55) HlirC4IA5  MAX5IZ£=bS  INVERT  55A 

5b(REPOKI5  mAXoIZc  = 35  I'IVcRT  aoA 

bDSHIPSS  MAXbIZ£=JC5  n.P^AT:  1‘IV.RT  51A 

Figure  B-1 
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1 . General 

The  scenarios  which  follow  emphasize  the  ad  hoc  query  capability 
of  the  pilot  system.  Pre-defined  reports  can  be  used  to  provide 
periodic  reporting  on  a demand  basis.  The  value  added  by  an  on-line 
capability  to  perform  this  pre-defined  function  to  a community  of 
users  throughout  the  logistics  environment  is  believed  to  be  signifi- 
cant. The  potential  benefits  of  coupling  a capability  of  this  nature 
to  a distributed  set  of  comprehensive  logistics  data  sets  (files) 
should  not  be  underestimated. 

What  follows  in  this  section  of  the  report  is  an  in-depth 
presentation  of  the  ability  to  access  diversified  sets  of  data  using 
an  ad  hoc  report  definition  and  query  capability.  It  is  this  ability  , 
to  get  questions  answered,  to  find  out  what  has  happened  and  is 
happening  in  terms  of  a common  English  language  which  is  easy  to 
use  and  understand,  that  makes  what  follows  so  significant. 

It  is  now  possible  to  incorporate  a wide  range  of  diversified 
logistics  data  into  an  integrated  structure  and  have  the  information 
available  via  a terminal.  Approximately  50  definitions  are  contained 
in  the  base  definition  being  demonstrated.  Once  the  architect 
defines  the  expanded  set  of  acronyms,  data  can  be  added  or  changed 
at  will  either  from  a remote  terminal  or  by  local  batch  operation. 

It  should  be  kept  in  mind  that  everything  which  follows  in  this 
section  of  the  report  was  done  with  SHARP,  but  once  developed,  the 
NAVLIS  Pilot  Model  will  possess  similar  capabilities  for  truly 
distributed  data  bases. 

The  ability  to  access  distributed  sets  of  data  from  a single 
standardized  query  system  is  thoroughly  demonstrated.  The  value 
added  by  such  an  approach  is  perhaps  best  demonstrated  in  the 
NAVLIS  Scenario  (see  Attachment  #6)  where  a projected  ship  schedule, 
budgeting  and  funding  information,  historic  overhaul  information, 
and  overhaul  duration  and  interval  standards  are  presented  in  one 
NAVLIS  report  for  the  entire  Atlantic  Fleet. 
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2,  LANTFLT  Scenario  I 

LANTFLT  Scenario  I is  an  information  scenario  which  presents 
budget  (apportionment)  data  and  actual  funded  costs  for  class  DD, 

DDG,  DLG,  and  DE  ships.  The  information  requirement  originates  in 
connection  with  a decision  relating  to  implementation  of  fixed  cost 
and  100%  overhaul  activity.  The  information  is  needed  for  each 
shipyard. 

The  scenario  begins  with  a definition  of  information  requirements 
in  Report  NF4.  Query  NF*  is  then  formulated  in  conjunction  with 
Report  NF4  to  retrieve  the  apportionment  information  for  fiscal  74. 
Query  NF*  is  repeated  in  the  scenario  for  fiscal  75  and  76. 

Query  NF  is  then  used  in  conjunction  with  Report  NF4  to  obtain 
the  FY73  apportionment  for  the  classes  of  interest.  It  is  interest- 
ing to  note  the  FY73  apportionment  does  not  contain  yard  information. 

LANTFLT  Scenario  I then  obtains  the  actual  funding  for  overhauls 
completed  by  first  defining  the  information  requirements  in  Report 
NF6  and  then  continuing  with  Query  NF*  to  obtain  the  actual  funding 
for  completed  overhauls  in  those  classes  of  interest.  Presentation 
of  this  information  ends  the  scenario.  See  Attachment  #1  for  a 
representative  report  and  terminal  session. 

3.  Historical  Scenario 

This  scenario  displays  information  from  the  historical  overhaul 
class  of  information  available  in  the  field  of  query. 

A report  NCI  is  defined  which  presents  the  man  days  required  to 
overhaul  a ship.  Since  the  first  portion  of  the  query  set  is  con- 
cerned with  new  construction  (NC),  the  start  date  and  commission 
date  are  the  event  markers  of  interest.  NCI  also  presents  sigma, 
maximum,  minimum,  average,  and  sum  information. 

Query  NCI  presents  information  about  SSBN  new  construction. 

Query  QSl  uses  Report  NCI  and  presents  new  construction  infc  mation 
for  FF  class  ships.  A second  question  in  Query  QSl  asks  for 
information  about  new  construction  on  ARS  class  ships.  The  response 
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produces  29  hits  for  FF  and  zero  hits  for  ARS,  indicating  that  no 
new  construction  information  for  class  ARS  ships  is  available  in 
the  field  of  query. 

As  the  ad  hoc  dialogue  with  the  machine  continues,  Query  QS2 
asks  three  questions.  The  first  two  use  Report  NCI.  The  third 
uses  another  pre-defined  report  (NAV)  contained  in  the  system. 

The  first  question  involves  new  construction  for  the  LST  class. 

The  second  question  asks  for  all  new  construction  which  was 
performed  in  Philadelphia.  The  third  question  asks  for  all  historic 
information  about  the  ARS  ships  based  on  the  information  content 
of  Report  NAV,  which  sets  forth  the  overhaul  type  and  start  and 
end  dates  for  the  overhaul,  as  well  as  the  yard  and  man  days. 

Notice  the  information  content  of  this  report  contains  no  NC  data, 
since  there  is  none  in  the  base  for  this  class. 

The  ad  hoc  scenario  continues  with  Query  QS3.  This  query  uses 
Report  NAV  but  brings  the  overhauls  down  by  start  date  in  accordance 
with  the  sort  criteria.  It  is  interesting  to  see  how  the  overhaul 
man  days  have  increased  over  the  years. 

Query  QS4  then  brings  the  NAV  ARS  overhaul  data  out  by  sorting 
on  hull  and  start  date  and  subtotals  on  the  actual  labor  days. 

This  presents  an  interesting  overhaul  report  for  class  ARS  ships. 

Query  QS6  calls  for  all  information  contained  in  the  data  base 
concerning  the  BELKNAP.  Notice  no  report  format  is  specified. 

This  results  in  a complete  printout  with  full  annotation  of  all 
information  contained  in  the  base.  Query  SET  then  terminates 
the  session  by  printing  the  budget  (apportionment)  information 
contained  in  the  base.  Notice  this  information  is  identified 
as  funding  activity  (fndactivity)  by  budget  year.  Since  sub- 
totals are  taken  on  fndactivity  and  the  fndactivity  is  also  the 
primary  sort  key,  the  data  are  listed  chronologically  by  budget 
years  73,  74,  75,  and  76.  See  Attachment  #2  for  representative 
reports  and  terminal  session. 
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4.  Ship  Funding  Scenario 

The  ad  hoc  scenario  starts  by  Query  003  asking  the  system  to 
print  the  hull  and  ship  of  all  ships  which  had  advanced  funding 
requirements  (APR)  as  of  July  31,  1974  and  a scheduled  end  date 
equal  to  or  less  than  7604  which  is  April  of  76.  We  learn  there 
were  five  such  ships. 

Since  it  is  desired  to  trace  the  funding  history  (profile)  of 
these  five  ships.  Report  003  is  defined  to  display  the  prior  year 
funding,  the  current  year  plan,  the  current  year  funding,  and  the 
estimated  current  year  requirement.  The  sub-totals  of  these  fields 
are  defined  in  the  report.  Query  004  then  calls  for  all  carry  over 
requirement  (COR),  current  fiscal  year  (CFY),  selected  restricted 
availability  (SRA),  or  advanced  funding  requirement  (APR)  type  of 
information  contained  in  the  data  base  to  be  displayed  in  accordance 
with  the  information  content  of  Report  003.  Data  are  to  be  sorted 
down  by  hull  and  as-of  date.  The  report  demonstrates  the  year-end 
roll-over  from  current  year  funding  to  prior  year  funding.  Sub- 
totals on  this  report  are  meaningless. 

Query  005  of  the  Query  set  in  this  scenario  then  calls  for  the 
budget  (apportionment)  information  on  these  ships  for  74,  75,  and 
76  fiscal  years.  The  ad  hoc  scenario  then  continues  by  defining 
a new  information  requirement  in  Report  005.  Query  006  then,  in 
conjunction  with  Report  005,  displays  the  funding  information  on 
the  same  five  ships  on  one  report. 

Query  007  then  uses  a pre-defined  report  PSB  to  display  all 
information  on  these  five  ships  in  the  base.  Report  PSB  is  sorted 
by  hull  and  as-of  date.  Report  PSB  does  not  display  the  hull. 

It  will  be  noticed  that  the  first  five  digits  of  the  RCDID  are  the 
ship  Die  code.  Query  008  simply  asks  the  system  to  print  the  hull, 
ship,  and  UIC  for  the  first  record  of  each  different  5-digit  UIC 
record  prefix.  The  printout  of  this  information  tells  what  hull 
is  associated  with  each  set  of  data  in  the  PSB  report.  See  Attach- 
ment #3  for  representative  reports  and  terminal  session  referred  to 
in  the  preceding  paragraphs. 
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5.  Scenario  Based  on  August  1975 


\ 


Funding  Report 


The  scenario  begins  by  defining  an  information  requirement  in 
Report  FND.  This  report  demonstrates  that  a great  deal  of  financial 
information  can  be  presented  on  a standard  ASR-33  type  terminal. 
Report  FLT  is  then  defined  as  the  second  step  in  the  scenario. 

This  report  sets  forth  scheduling  information  based  on  end  date  of 
the  overhaul. 

Query  S03  then  presents  the  funding  situation  by  ship  as  of 
August  31,  1975.  Report  SCD  (pre-defined)  presents  the  basic  hull, 
ship,  year,  start  date,  end  date,  and  funding  activity  for  that 
ship.  The  data  are  presented  in  the  order  of  original  entry  by 
sorting  on  the  record  key  suffix. 

It  is  then  recognized  that  Report  FND  has  been  improperly 
defined  because  the  funding  activity  was  not  called  for  in  the 
print  statement.  The  error  is  corrected  by  simply  re-defining 
Report  FND.  We  then  proceed  with  the  scenario  by  using  Query 
S03  to  print  the  detailed  funding  information  for  each  ship  in 
the  August  31,  1975  report  in  accordance  with  Report  FND  require- 
ments. Although  the  data  base  contains  all  necessary  cross  foot- 
ing, notice  a 132-character  printer  (presently  available  at  remote 
terminals)  would  really  be  required.  This  cross  footing  is  displayed 
later. 

Query  S03  is  then  continued  in  the  scenario  by  calling  for  all 
ships  due  to  be  completed  in  FY76  to  be  reported  in  accordance 
with  the  previously  defined  FLT  Report.  Data  are  to  be  sorted  by 
end  date  (date  ships  leave  the  yard).  The  information  is  presented 
chronologically.  See  Attachment  #4  for  the  representative  reports 
and  terminal  session  referred  to  in  the  preceding  paragraphs. 


6.  Ship  Funding  Profile  Scenario 


This  scenario  commences  with  the  definition  of  an  information  I 

requirement.  Information  about  how  the  estimates  of  a thorough 
overhaul  vary  during  the  overhaul,  along  with  the  estimates  of  the 
requirements  for  the  present  year  and  the  actual  funding  for  the 
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present  year,  is  desired. 

The  analyst  also  needs  to  know  how  much  money  each  yard  has 
received  by  ship  for  fiscal  75.  Sub-totals  are  taken.  This  information 
requirement  is  defined  in  the  YRD  Report  as  the  second  step  in  the 
ad  hoc  scenario. 

Query  ***  then  wants  to  know  the  hull  and  ship  name  of  all  ships 
which  were  reported  as  of  January  31,  1975  as  having  started  an 
actual  overhaul  (75  CFY)  that  month.  Query  *1*  then  calls  for  a 
funding  profile  of  these  ships  starting  July  31,  1974  through 
August  31,  1975.  Report  PRO  presents  the  information  in  accordance 
with  the  sort  requirements. 

The  scenario  continues  with  Query  *2*.  This  query  asks  the 
question  and  gets  the  answer  to  how  the  various  yards  were  funded 
for  that  year. 

The  scenario  continues  with  Query  *3*.  Pre-defined  Report  EST 
is  used.  This  report  prints  the  current  year  funding  and  the  funding 
activity  for  ship,  yard,  start  date,  and  end  date.  Query  *3*  is 
submitted  again  and  the  gate  is  widened  to  let  all  year  end  data 
associate  and  correlate  in  Report  QRY.  (To  demonstrate  the  graceful 
degradation  of  the  system  and  how  the  information  is  still  not  lost-, 
another  query  is  formulated,  the  76  Budget  data  are  included,  and  the 
387  hits  are  printed  on  the  computer  room  printer.)  See  Attachment 
#5  for  representative  reports  and  terminal  session. 

7 . NAVLIS  Scenario 

The  NAVLIS  Scenario  begins  by  an  ad  hoc  information  requirement 
consisting  of  17  fields  of  information.  For  each  ship  the  user  would 
like  to  know  the  overhaul  historical  profile,  the  budgeting  profile, 
the  estimated  overhaul  cost  for  any  actual  funding  which  may  have 
been  recorded,  and  the  relevant  overhaul  standards.  The  next  hypothetical 
overhaul  is  also  requested.  All  this  information  is  to  be  appropriately 
time-sequenced  on  the  printout. 

The  wealth  of  information  which  can  be  made  available  in  a NAVLIS 
type  system  from  a nucleus  of  approximately  50  elements  is  very  large. 


307 


Much  information  in  the  base  is  not  contained  in  this  report. 

We  could  also  ask  questions  about  dates,  home  yards  and  overhaul 
yards,  ships,  etc.  See  Attachment  #6  for  representative  reports 
and  terminal  session. 

8 . Ship  Identification  Scenario 

This  scenario  demonstrates  how  the  architecture  of  the  system 
functions  at  the  directory  level. 

Query  DO  asks  10  questions  about  ship  identification.  The 
power  and  flesibility  of  the  system  in  its  handling  of  information 
is  demonstrated  in  the  reports  which  are  shown  in  Attachment  #7. 

The  reader  should  take  special  note:  All  the  user  is  doing  in 

Query  DO  is  asking  questions.  The  system  automates  the  answer. 

Once  the  user  has  the  ship  names,  hull,  and  UIC,  he  can  ask  any 
question  using  any  of  the  three. 

The  Ship  Identification  Scenario  is  closed  with  a question 
about  the  Sunbird.  The  Sunbird  is  a member  of  the  class  ASR. 

The  NAVLIS  report  tells  us  all  about  ASR  ships.  See  Attachment  #7 
for  representative  reports  and  terminal  session. 

9.  LANTFLT  Scenario  II 

This  scenario  clearly  demonstrates  the  ability  of  the  user  to 
obtain  his  information  under  less  than  optimum  conditions.  The 
scenario  seeks  information  about  LST  and  DE  overhauls.  It  com- 
mences with  Query  WES  and  obtains  a printout  of  the  LST  ships 
overhauled  in  Fiscal  75  and  the  first  two  months  of  Fiscal  76. 
Report  WES  is  then  defined  to  obtain  information  about  the  actual 
funding.  The  scenario  continues  with  Query  WES,  which  provides 
no  hits  because  of  the  way  in  which  not  equal  (NE)  is  used. 

Query  WES  is  again  formulated  based  only  on  the  carry  over  require- 
ment (COR)  funding  qualifier.  Fifty-five  hits  are  produced  and 
printed  in  batch.  Query  WES  then  is  input  again,  this  time  using 
all  relevant  funding  qualifiers.  Eighty-one  hits  are  produced 
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and  the  user  incorrectly  calls  for  them  on  the  terminal. 

Query  WES  is  aborted  and  again  submitted  and  the  output  is 
taken  in  batch  as  it  should  be  because  of  the  130-column  report 
definition.  The  output  presents  a funding  profile  of  the  ship 
overhaul . 
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CINCLANTFLT 

^ Scenario  I 

I 

Terminal  Session  and  Report  Samples 


C 6700  INTERCOM  V4.2 
DATE  11^12^75 
TIME  12.03.25. 

PLEASE  LOGIN 

LOG  I N . PUMEUIEfl VER » 11 3 06  0 0823 » SUP 
COMMAND-  ETL.500 
COMMAND-  COMRADE* SHARP 


COMRADE  TIME:  12.04.23. 

DATE:  11/12/75 

SHARP  SUBSYSTEM  ENTERED 
????  REPDEF 


PLEASE  INPUT  REPORT  DEFINITIONS. 

ID  BASE2 
REPORT  NF4 
DBTYPE  IS  RCDID 

MHEAD  SAPPORTIONMENT  INFORMATION  - ATLANTIC  FLEET'* 

COL  HEAD  1|=  *YARD* 

COL  HEAD  22=  *HULL* 

COL  HEAD  3 = *SHIP* 

COL  HEAD  4 = SLABOR/MONEY/ O 000> $ 

COL  HEAD  5 = 8MATL/M0NEY/ (1 000) * 

COL  HEAD  6 = '5UNIT/COST/ <1  000)  * 

PRINT  FCLTY.  HULL.  SHIP.  BDGTLMNY.  BDGTMMNY.  BDGTUCOST 

PRINT  SUBTOTAL  BDGTLMNY.  BDGTMMNY.  BDGTUCOST  ON  FCLTY 

PRINT  TOTAL  BDGTLMNY.  BDGTMMNY.  BDGTUCOST 

PRINT  MAX  BDGTLMNY.  BDGTMMNY.  BDGTUCOST 

PRINT  MIN  BDGTLMNY.  BDGTMMNY.  BDGTUCOST 

PRINT  SIGMA  BDGTLMNY.  BDGTMMNY.  BDGTUCOST 

SEND 


REPORT  DEFINITION  ERROR  SUMMARY 
ID  - BASE2 


REPORT  - NF4 

NO  ERRORS  FOUND  - REPORT  DEFINITION  ACCEPTED 
?■???  IQUERYX 


YOU  HAVE  SELECTED  THE  INTERACTIVE  QUERY  OPTION. 
WOULD  YOU  LIKE  AN  EXPLANATION  OF  THE  SYSTEM^-NO 


SELECT  ONE  OF  THE  FOLLOWING  DATA  BASES 
18  LOGISTICS  DOCUMENT  DATA  BANK 

31  YURSO  DATA  BANK 

32  MKRS-BASE-2 
??  32 


PLEASE  INPUT  QUERY  COMMANDS 


i 


j 


' LDV  Ef?R  0003 

■i  OVERLflY  MOT  FQUMD 

QUERY  NF* 

IF  FWOftCTVTY  IS  74BDGT? 

. AND  PREFIX  HULL  IS  OD-^ 

AND  PREFIX  HULL  IS  NE  TO  DDG^ 
REPORT  NF4 
SORT  ON  FCLTY 

HEAD  1 fOUACLASS  - FISCAL  1974* 
IF  FNDACTVTY  IS  74EDGT7 
AND  PREFIX  HULL  IS  DDG' 

REPORT  NF4 
SORT  ON  FCLTY 

HEAD  1 fDDG  CLASS  - FISCAL  1974'I 
IF  FNDACTVTY  IS  74BDGT7 
AND  PREFIX  HULL  IS  DLG^ 

\ REPORT  NF4 

, SORT  ON  FCLTY 

HEAD  1 'SDLG  CLASS  - FISCAL  1974* 
[ IF  FNDACTVTY  IS  74BDGT? 

f AND  PREFIX  HULL  IS  DE^ 

I AND  PREFIX  HULL  IS  NE  TO  DEG^-' 

REPORT  NF4 

j SORT  ON  FCLTY 

j HEAD  1 8DE  CLASS  - FISCAL  1974* 

L *END 

[ i YOUR  QUERY  HAS  BEEN  ACCEPTED 


FOR  EACH  QUESTION?  TYPE  IN  D?  T.  OR  B. 


QUERY 

NF»? 

QUESTION 

NO. 

1 J 

HAS 

HITS-T 

QUERY 

NF*. 

QUESTION 

NO. 

HAS 

4 

HITS-T 

QUERY 

NF*? 

QUESTION 

NO. 

3^ 

HAS 

4 

HITS-T 

QUERY 

NF»? 

QUESTION 

NO. 

4 9 

HAS 

£ 

HITS-T 

RPPDRTIQNMEMT  INFDPMRTIQN  - RTLRMTIC  FLEET 


DD  CLRSS  - FISCHL  1974 


REPORT  NF4  NF*001 

NOV  18  1975 

YARD  HULL 

SHIP 

LABOR 
MONEY 
<1  000> 

MATL 

MONEY 

<1000) 

UNIT 
COST 
< 1 0 0 0 ) 

RCDID 

PH  DD  880  RICH 

8438 

431 

581808673 

♦♦♦SUBTOTAL*** 

8438 

431 

£869 

3 

DD  835 

CECIL 

859  0 

488 

3018 

581358679 

3 

DD  839 

POMER 

8609 

448 

3051 

581398680 

3 

DD  868 

V08ELGESANG 

8136 

348 

8473 

581688681 

3 

DD  863 

STEINAKER 

8506 

485 

8931 

581638688 

♦♦♦SUBTQTHL*** 

9841  1637  11478 

♦♦♦♦♦TOTAL**** 


REPORT  NF4 

NF*002 

NOV  12  1975 

YfiRD 

HULL 

SHIP 

LABOR 

MATL 

UNIT 

MONEY 

MONEY 

COST 

aooo> 

(lOOOJ 

aooo> 

RCDID 

C 

DDG  11 

SELLERS 

4277 

626 

4903 

046772648 

C 

DD6  18 

SEMMES 

4 391 

653 

5044 

046842649 

♦♦♦SUBTOTAL*** 

8668 

1279 

9947 

M 

DDG  5 

RICKETTS 

3608 

733 

4341 

046712643 

♦♦♦SUBTOTAL*** 

3608 

733 

4341 

PH 

DDG  6 

BRRNEY 

3732 

728 

4460 

046722637 

♦ ♦♦SUBTDTFIL*** 

3732  728  4480 

♦♦♦♦♦TDTRL**** 

16008  2740  18748 

♦ ♦♦CIRXIMUM**** 

4391  733  5044 


; ♦♦♦tllNItlUM**** 

i LDV  ERP  0003 

• aVERLflY  MOT  FaUND 


I 


i 


REPORT  MF4  MF*003 


NQV  12  1975 


YRRD 

HULL 

SHIP 

LHBOR 
MONEY 
Cl  000> 

MATL 
MONEY 
Cl  000> 

UNIT 
COST 
Cl  000.) 

RCDID 

C’ 

DLG  28 

WRINWRIGHT 

3533 

592 

4125 

527032847 

♦♦♦SUBTOTAL*** 

3533 

592 

4125 

M 

DLG  27 

DRMIELS 

2875 

375 

3250 

527022842 

♦♦♦SUBTOTAL*** 

j 

2875 

375 

3250 

! 

1 PH 

! PH 

DLG  6 
DLG  17 

FRRPRGUT 

YRRNELL 

5 053 
3 048 

1225 

414 

8278 

3482 

522312635 
*5  £ 1 

mPPOPTIQMMEMT  INFOPMATIOM  - ATLANTIC  FLEET 


DE  CLASS 

- FISCAL 

1974 

REPORT 

NF4  NF*004 

NOV  1£  1975 

YARD 

HULL  SHIP 

LABOR 

MONEY 

<1000^ 

MATL 

MONEY 

<1000.» 

UNIT 

COST 

<1000; 

RCDID 

C 

DE  1049  KDELSCH 

£601 

54£ 

3143 

54044£651 

♦♦♦SUBTOTAL*** 


£601 

54£ 

3143 

PH 

DE  1056  CANNOLE 

£337 

4££ 

£759 

54051£638 

♦♦♦SUBTOTAL*** 

£337  4££  £759 

♦♦♦♦♦TOTAL**** 

4938  964  590£ 

♦ ♦♦MAXItlUM**** 

£601  54£  3143 

♦♦♦MINIMUM**** 

£337  4££  £759 

♦♦♦♦SIGMA***** 

13£  60  19£ 


I 


MOULD  YOU  LIKE  TO  SUBMIT  ftNDTHEP  OUERY?-  YES 


PLEASE  INPUT  QUEPY  COMMANDS 

LDV  EPP  0003 
OVEPLAY  NOT  FOUND 
QUERY  NF* 

IF  FNDACTVTY  IS  7S.BDGT? 

AND  PREFIX  HULL  IS  DD' 

AND  PREFIX  HULL  IS  NE  TO  DUG? 
REPORT  NF4 
SORT  ON  FCLTY 

HEAD  1 i-DD  CLASS  - FISCAL  l?75f 
IF  FNDACTVTY  IS  7SBDGT7 
AND  PREFIX  HULL  IS  DDG^ 

REPORT  NF4 
SORT  ON  FCLTY 

HEAD  1 IDDG  CLASS  - FISCAL  197SI; 
IF  FNDACTVTY  IS  75BDGT7 
AND  PREFIX  HULL  IS  DLG'^ 

REPORT  NF4 
SORT  ON  FCLTY 

HEAD  1 '{.DLG  CLASS  - FISCAL  1975'f 
IF  FNDACTVTY  IS  75BDGT7 
AND  PREFIX  HULL  IS  DE? 

AND  PREFIX  HULL  IS  NE  TO  DEG^ 
REPORT  NF4 
SORT  ON  FCLTY 

HEAD  1 tDE  CLASS  - FISCAL  197S.I. 
■SEND 

YOUR  query  has  been  accepted 


! 

i 

I 

i 

I 

i 

i 


i 

j 

! 

i 


FDR  EACH  QUESTION.  TYPE  IN  D.  T.  DP  B. 


QUERY 

QUESTION 

NO. 

1 < 

HRS 

1 1 

hit:-t 

^ QUERY 

QUEST  I ON 

NO. 

c’  * 

HRS 

c 

hit:-t 

OUEPY 

4 

QUESTION 

NO. 

5* 

HRS 

hit:-t 

’ OUEPY 

UP  #4 

QUESTION 

NO. 

4. 

HRS 

4 

hit:-t 

3 


i 


j 


HPPQRTiamENT  INPDRMfiTIDN  - flTLHNTIC  FLEET 
DD  CLfiSS  - FISCAL  1975 

REPORT  MF4  NF*001 


MOV  12  1975 


YftPD 

HULL 

SHIP 

LABOR 

MATL 

LIMIT 

MOMEY 

MOMEY 

COST 

< 1 0 0 0> 

<10  0 0 > 

<1  0 00) 

RCDID 

C: 

DD  937 

DAVIS 

6*684 

964 

7648 

521972548 

c 

DD  938 

IM8PAM 

6 6 cl  6 

976 

76  02 

521982549 

♦♦♦SUBTDTAL^^^ 

1331  0 

194  0 

1525  0 

* 

M 

DD  941 

DU  POMT 

6131 

1 Oc'3 

7154 

522002542 

M 

DD  943 

BLAMDY 

5944 

998 

6937 

522022543 

♦♦♦SUBTOTAL^^^ 

12075 

£ 0 1 6 

14  091 

PH 

DD  714 

RUSH 

4782 

686 

5468 

043142502 

PH 

DD  724 

LAFFEY 

450  0 

688 

5138 

043242500 

PH 

DD  82  0 

RICH 

4782 

686 

5468 

521202501 

PH 

DD  94  0 

MAMLEY 

642  3 

1 03  0 

7453 

52 1 992535 

♦♦♦SUETOTAL^^^ 

£0487 

304  0 

23527 

SJ 

DD  89  0 

MEREDITH 

3916 

78S 

4551 

521902513 

LDV  ERR  001X3 
OVERLAY  MOT  FOUMD 
DATA  E:ASE  - E:AtE2 


♦ ♦♦SUB TOTAL ♦♦♦ 


DO  319  HOLDER 


4450  715  5165 


521192508 


♦♦♦SUBTOTAL^^^ 

4450  715  5165 


DD  763  LAI, IE 


3749  731  4480 


0386325 1 0 


318 


RPPORTiaMMENT  INFORURTIDN  - RTLRNTIC  FLEET 


DD  CLRSS  - FISCRL  1975 


REPORT  RF4  NF*001 


MOV  12  1975 


YRRD  HULL 


LREOR  MRTL  UMIT 

MONEY  MONEY  COST 

(100  CO  <1  00  0>  (100  Co 


♦♦♦SUETDTRL*** 


5749  731  4430 


♦♦♦♦♦TDTRL**** 


57887  9177  67084 


♦♦♦MRXIMUM**** 


6684  1030  7648 


♦♦♦MINIMUM**** 


3749  638  4480 


****SI  i3MR***** 


1067  152  1203 


319 


RPPOPTIDNMEMT  INFORtlRT  I ON  - PITLFINTIC  FLEET 


i 

( 


I 


' > 


ririi3  CLRSS  - FISCRL  1975 


REPORT  MF4  NF»00a  riOV  12  1975 


VRR'D 

HULL 

‘HIP 

LR£:DR 

MRTL 

UN  I T 

MONEY 

MONEY 

COST 

<1  00  0> 

< 1 000> 

(.  1 0 0 0 > 

PC  II I n 

c 

DDG  19 

TRTTMRLL 

7116 

1 161 

8277 

046852547 

♦ ♦•iUB:TOTRL*** 

7116 

1 161 

8277 

N 

nnu  17 

CONVHRHRM 

6556 

1 189 

7745 

046832540 

M 

DBu  2 3 

B:YPD 

6554 

1187 

7741 

046902541 

♦ ♦♦SUE:TOTRL*** 

1311  0 

2376 

15486 

PH 

DDI3  2 

hdrhs 

6785 

121  I 

7996 

046682526 

PH 

riDi5  3 

K I MR 

6812 

1228 

8 04  0 

046692527 

♦♦♦iUFTOTRL*** 

13597  2439  16036 

♦♦♦♦♦TOTRL»*»* 

5 3FI23  5976*  39799 

♦♦♦RRX IMUM**** 

7116  1228  8277 

♦ ♦♦MINim.lN**** 

6554  1161  7741 

207  23  201 


Lb 


1 


320 


RPPOPT lOHMENT  INFDPMRTIDN  - RTLhMTIC  FLEET 
DLG  CLRSS  - FISCAL 

PEPQPT  NF4  MF*003 


YARD 

HULL 

SHIP 

LABOP 
MONEY 
<1  OOil) 

MATL 
MONEY 
■ 1 0 0 u ) 

UN  I T 
COST 
• 1 000) 

PC  n I ri 

c 

DLG  14 

DEI.IEY 

G070 

■?43 

7013 

586858546 

♦♦♦iUBTDTAL*** 

6 07  0 

848 

7 0 1 3 

H 

DLG  34 

BilDDLE 

5587 

885 

3433 

587088538 

♦♦♦ ; UBTDTflL*** 

8'“*^  84‘^c 

11687  184?  15510 

6 07  0 848  7018 

♦♦♦M IH I 

5587  885  6488 

♦ ♦♦♦ 5 1 

836  87  865 


321 


flPpaRTIOMMENT  INFOPHftTIDN  - flTLPiNTIC  FLEET 


If 


! 


DE  CLFlSS 

- FISCRL 

1975 

PEPOPT  MF4  NF*004 

NDV  12  1975 

Y8PD  HULL 

SHIP 

LfiBQR 

MRTL 

UN  I T 

NOHEV 

MQHEY 

COST 

Cl  00  0> 

O 000> 

< 1 0 0 0 > 

Reran 

C HE  1 047 

VO'SE 

4954 

761 

5715 

540422550 

C HE  1 072 

ELHC  ELY 

4848 

760 

56  08 

540672551 

♦♦♦SUETQTflL*** 


98  02 

1521  1152:3 

PH 

DE 

1 0 38  NC  CLOY 

2189 

589  2578 

‘?4  036a5£8 

PH 

HE 

1059  SIMS 

4572 

754  5325 

540542529 

1 

♦ ♦♦SUE:TQTFIL*** 

6761  1143  7905 

*****TaTflL**** 

16’563  i2664  19££6 

♦ ♦♦MRXIHIJM**** 

4954  761  5715 

♦ ♦♦MIHIflUM**** 

3189  589  8578 

♦ ♦♦♦■'IiSMh***** 

1155  160  1894 


322 


1 


MOULD  YOU  LIKE  TO  SUDMIT  fiNOTHER  OUEPY?-  YES 

PLEASE  INPUT  OUEPY  COMMANDS 

LDV  EPR  0003 
OVERLAY  NOT  FOUND 
QUERY  NF* 

IF  FNDACTVTY  IS  7t.BDbT^ 

AND  PREFIX  HULL  IS  DD'? 

AND  PREFIX  HULL  IS  NE  TO  DDG'? 

REPORT  NF4 
SORT  ON  FCLTY 

HEAD  1 iDD  CLASS  - FISCAL  1376'!: 

IF  FNDACTVTY  IS  ?6EDGT'T 
AND  PREFIX  HULL  IS  DDb' 

REPORT  NF4 
SORT  ON  FCLTY 

HEAD  1 SDDb  CLASS  - FISCAL  1'37F.'J 
IF  FNDACTVTY  IS  7ADDGT? 

AND  PREFIX  HULL  IS  DLG'^ 

REPORT  NF4 
SORT  ON  FCLTY 

HEAD  1 I'DLg  class  ~ FISCAL  1976!' 

IF  FNDACTVTY  IS  76EDGT' 

AND  PREFIX  HULL  IS  DE'^ 

AND  PREFIX  HULL  IS  NE  TO  DEG'- 
REPORT  NF4 
SORT  ON  FCLTY 

HEAD  1 i.DE  CLASS  - FISCAL  1376'I. 

■TEND 

YOUR  QUERY  HAS  BEEN  ACCEPTED 


FOR  EACH  QUESTION.  TYPE  IN  D.  T.  OP  B. 


QUERY 

NF*. 

QUESTION 

NO. 

1 . 

HAS 

1 1 

HITS 

QUERY 

NF*. 

QUESTION 

NO. 

HAS 

s 

HITS 

. QUERY 

NF*. 

QUESTION 

NO. 

5 ' 

HAS 

0 

HITS 

QUERY 

NF*. 

QUESTION 

NO. 

4. 

HAS 

0 

HITS 

i 

i 

i 

i 


flPPOPTIOMHEMT  IMFOPMPTIDN  - PTLPMTIC  FLEET 


i.  ^ .11.  .1 


DD  CLM5S 

- FI  SC  ML 

1976 

REPORT 

MF4  HF*001 

VRRD 

HULL  SHIP 

LMDDP 

MMTL 

UN  I T 

nDMEV 

MONEY 

COST 

' 1 0 0 0 ' 

< 1 0 0 0 > 

< 1 OOCu 

HOV  1975 


PC  Din 


1 

I 

I 

j 

i 

I 


PH 

DD 

9 '5  3 

DMPPY 

9638 

1714 

11859 

591985695 

DD 

94  0 

MMNLEY 

9688 

1796 

11494 

591995691  ] 

♦♦♦SUETDTML*** 

] 

i 

i 

19866 

35 1 0 

99776 

DD 

9c’£ 

MCCMPD 

391  1 

?18 

4899 

581885617  j 

s J 

DD 

866 

CONE 

5707 

379 

4586 

581665615 

♦ ♦♦■iUETaTfiL*** 


1 

76 1 8 

1 797 

94  1 5 

DD 

891 

JOHNSTON 

391  1 

859 

4 76? 

591915600 

-jj 

DD 

849 

F I S>  E 

4 4 y 9 

1 006 

5495 

591495601 

1 3 

DD 

864 

ELLISON 

4981 

9 06 

5187 

591645619 

' 3 

DD 

871 

DMMMTD 

4715 

1 079 

5794 

59 1715618 

DD 

88  0 

DYESS 

461  5 

1 0 54 

5647 

591SO5t09 

DD 

931 

SHtPMMN 

8499 

1895 

1 0947 

59 1 9 1 564 1 

DD 

94  3 

E'LHr<Ci  V 

8884 

18  07 

1 0091 

588085648 

< 

» 

• •• : 1 IDTOTML*** 

58715 

85  0'^ 

4 7 8 8 4 

: 

6559  ? 

1 3816 

794  1 5 

• ••MM  IMl.iM**** 


I 

I 

1 


9659  1895  11494 

••♦M I M I MMM***« 

5707  859  4586 

•••• 

9 5 4 1 4 1*1  M 97  58 


•1 

i 

•5 

•< 

-< 

i 


L324 

1 i 


APPORTIONMENT  INFORMATION  - ATLANTIC  FLEET 


DDA  CLASS  - FISCAL  1976 


REPORT  NF4  NF*00£  NOV  IE  197? 


YARD 

HULL 

SHIP 

LABOR 

MATL 

UN  I T 

MONEY 

MONEY 

COST 

a 000) 

f 1 0 0 Cl ) 

(.10  0 0 > 

PC  DID 

c 

DBG  19 

TATTNALL 

1 0422 

1720 

12142 

♦♦♦SUBTOTAL*** 

1 0422 

1720 

12142 

N 

DDG  4 

LAMRENCE 

5973 

1 79?i 

1 0772 

I34P,TT|5P,'^  n 

N 

DDG  23 

BYRD 

5569 

1535 

1 0704 

0469056^9 

♦♦♦SUBTOTAL*** 

17342 

3634 

2 1 476 

PH 

DDG  10 

SAMPSON 

9445 

1567 

11312 

04b7<;.T-t££ 

PH 

DDG 

LUCE 

1 0254 

2230 

12534 

522325623 

♦♦♦SUBTOTAL*** 

19699  4147  23646 

♦♦♦♦♦TOTAL**** 

47963  9?!  01  57464 

♦ ♦♦rihix  imum**** 

10422  2230  12534 

♦♦♦MINIMUM**** 

3569  1720  10704 


♦♦♦♦SI6MA***** 


WOULD  YOU  LIKE  TO  SUBMIT  (=lNOTHER  OUERY?-  YES 

PLEASE  INPUT  QUERY  COMMANDS 

LDV  ERR  0003 
OVERLAY  NOT  FOUND 


QUERY  NF 

IF  SHIP  IS  SPARROW  BDELETE 
IF  FNDACTVTY  IS  73BDi5T7 
AND  PREFIX  HULL  IS  DD‘ 

AND  PREFIX  HULL  IS  NE  TO  DDG^ 
REPORT  NF4 

BEAD  1 *DD  CLASS  - FISCAL  1973'I. 
IF  FNDACTVTY  IS  73BD3T7 
AND  PREFIX  HULL  IS  DDG' 

REPORT  NF4 

HEAD  1 'BEDS  CLASS  - FISCAL  197  3i. 
IF  FNDACTVTY  IS  73BDGT" 

AND  PREFIX  HULL  IS  DLG‘ 

REPORT  NF4 

HEAD  1 -BIiLG  CLASS  - FISCAL  1973t 
IF  FNDACTVTY  IS  73BDGT'? 

AND  PREFIX  HULL  IS  DE-? 

AND  PREFIX  HULL  IS  NE  TO  DEG^ 
REPORT  NF4 

HEAD  1 'BDE  CLASS  - FISCAL  1973B 
BEND 

YOUP  QUERY  HAS  BEEN  ACCEPTED 


FOP  EACH 

QUEST I 

ON. 

TYPE 

IN  D' 

• T.  OP  B. 

QUERY 

NF 

< QUES 

TION 

NO. 

1 - 

HAS 

1 0 

HITS 

QUERY 

NF 

* QUES: 

TIDN 

NO. 

c’ ' 

HAS 

0 

HITS 

QUERY 

NF 

< QUES 

TION 

NO. 

3* 

HAS 

HITS' 

QUERY 

NF 

!.  QUES 

TION 

NO. 

4. 

HAS 

1 

HITS 

1 


<•  ■■ 
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RPPQRTIDMMENT  IMFQRMRTinN  - fiTLRMTIC  FLEET 
DD  CLASS  - FISCAL  1973 


REPORT  NF4  NF 

001 

NOV  13  197' 

YARD  HULL 

SHIP 

LABOR 

MATL 

UNIT 

MONEY 

MONEY 

COST 

<1000) 

<1000) 

<1000) 

PCD  ID 

DD  333 

MCCARD 

3334 

515 

3399 

531333613 

DD  341 

NOA 

1697 

537 

3334 

531413583 

DD  850 

KENNEDY 

3606 

533 

3138 

531503589 

DD  364 

ELLISON 

3549 

533 

3071 

531643614 

DD  865 

WARE 

3047 

545 

3593 

531653590 

DD  371 

DAMATO 

3338 

566 

3394 

531713591 

DD  873 

VESOLE 

3 047 

545 

3593 

531733593 

DD  333 

PERRY 

36  39 

533 

3167 

531333593 

DD  943 

BIGELOW 

3965 

533 

3503 

533013594 

DD  944 

MULL  INN IX 

3718 

56  0 

3378 

533033595 

♦♦♦SUBTOTAL*** 

c'6  930  5363  33343 

♦♦♦♦♦TOTAL**** 

36930  5363  33348 

♦♦♦MAXIMUM**** 

3047  566  3593 

♦♦♦MINIMUM**** 

1697  515  3334 

♦♦♦♦SIGMA***** 

375  16  380 


327 


ftPPDRTiaNMENT  IMFOPMPTiaN  - PTLRMTIC  FLEET 


I 


>1 


, I 

i 


fi 


i 

i 

\ 

k 


DLG 

CLRSS  - FISCHL 

1973 

f 

REPORT  MF4  NF 

003 

NOV  12  1975 

5 

r 

i 

YRRD  HULL 

SHIP 

LRBDR 

MRTL 

UNIT 

f, 

r 

MONEY 

MONEY 

COST 

<1  000) 

<1000) 

<1  000> 

RCrUD 

1 

r 

HLG  IE. 

LEHHV 

2833 

591 

3479 

523372585 

f 

DLG  23 

MR  IHKIPIGHT 

3289 

539 

3378 

527032583 

DLG  32 

STRMDLEY 

3271 

535 

3353 

527072587 

f 

t 

i 

♦♦♦SUETOTRL*** 

j: 

9443 

1735 

11213 

j. 

i'i 

♦♦♦♦♦TOTRL**** 

/ 

i 

9443 

1 735 

11213 

♦♦♦MRXIMUM**** 

); 

f 

i 

3239 

591 

3373 

(. 

i': 

p ;I;  p, 

585 

3479 

< 

1 

i 

♦♦♦♦ S I GMR***** 

j 

183 

1 35 

li 


r 
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RPPDPTIDMflENT  INFDPMmTIDN  - PTLRMTIC  FLEET 


♦♦♦SUBTOTHL*** 

8155  416 

♦♦♦♦♦TDTPL**** 

8155  416 

♦ ♦♦MAX  I f1IJM**** 

8155  416 

8155  416 

♦ ♦♦♦  il GMh***** 


DE  CLASS 

- fiscal 

197  3 

MF4  NF 

004 

NOV  18  1-375 

HIJLL 

:hip 

LAEDP 

MAIL 

UN  I T 

MONEY 

MONEY 

COST 

C 1 0 0 0 > 

' 1 0 0 0 ' 

' 1 OOO’ 

PCD  ID 

HE  1 04  3 

NCnoriMELL 

8155 

416 

8571 

54  03985'36 

329 


WOULD  YOU  LIKE  TO  SUBMIT  ANOTHER  OUERY?-  NO 
????  REPDEF 


PLEfiSE  INPUT  REPORT  DEFINITIONS. 


ID  BASES 
REPORT  NF6 
DETYPE  IS  PCD  ID 
MHEAD  'SFUNDING  SUMMARY 
COL  HEAD  1 = EYAPD'E 


ATLANTIC  FLEET* 


COL  HEAD 
COL  HEAD  S 
COL  HEAD  4 
COL  HEAD  5 
COL  HEAD  e 


o - 


*HULL* 

SEND  DATE* 

SSTART- DATE* 

SEST.-  OVHL  ■ a000>* 

STDTAL  -FNDNG-'  a 000)  * 

COL  HEAD  4?  = SPER^CENT/DVHL* 

PRINT  FCLTY>  HULL.  ENDATE.  STARTDATE.  ESTDVHL.  TOTFND.  PERCNTDVHL 

PRINT  SUBTOTAL  ESTOVHL.  TOTFND  ON  FCLTY 

PRINT  TOTAL  ESTOVHL.  TOTFND 

PRINT  MAX  ESTDVHL  TOTFND 

PRINT  MIN  ESTDVHL.  TOTFND 

PRINT  SIGMA  EETDVHL.  TOTFND 

SEND 


REPORT  DEFINITION  ERROR  SUMMARY 
ID  - BASES 


REPORT  DEFINITION  ACCEPTED 


REPORT  - NFG 
NO  ERRORS  FOUND 

7 7 77 

EX  ID=  CADC  PFN=DATADEFFILE 

EX  CY=  001  00001G41  PPUS  *0004.10  ■'DAY 

IQUEP'r 


I'DU  HAVE  SELECTED  THE  INTERACTIVE  QUERY  OPTION. 
WOULD  YOU  LIKE  AN  EXPLANATION  OF  THE  SYSTEM7-ND 


SELECT  ONE  OF  THE  FOLLOWING  DATA  BASES 
IS  LOGISTICS  DOCUMENT  DATA  BANK 
■31  YUPSD  DATA  BANK 
3S  MKRS-BAiE-S 

77 


'^■LEASE  ENTER  QUERY  MODE  OPTION. 

ENTER  A FD'”'  ADVANCED.  T FOP  TUTDRIAL-A 


PLEASE  INPUT  QUERY  COMMANDS 


1 
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LDV  ERR  0003 
□VERLI3Y  NOT  FOUND 
QUERY  NF* 

IF  RSQFDFITE  IS  750630^ 
fiND  EMDRTE  IS  BE  TO  74 
FIND  PREFIX  ENDfiTE  IS  EE  TO  7907  7506'' 

FIND  PREFIX  HULL  IS  DD? 

HMD  PREFIX  HULL  IS  NE  TO  DDG^ 

REPORT  NF6 
SORT  ON  FCLTY 

HERD  1 tDD  CLFISS  - FISCHL  75  COMPLETIONS* 
IF  flSDFDHTE  IS  750630? 
mND  ENDFiTE  IS  BE  TO 

Find  prefix  endhte  is  be  to  7407- 7506'' 
hND  prefix  HULL  IS  DDC? 

REPORT  NF6 
SORT  ON  FCLTY 

HERD  1 *DDG  CLRSS  - FI  SCRL  75  CDMPET I DNS* 
IF  RSOFDRTE  IS  750630^ 

RND  ENDRTE  IS  BE  TO  74  07 '75 06? 

RND  PREFIX.  HULL  IS  DL6‘ 

REPORT  NF6 
SORT  ON  FCLTY 

HERD  1 iDLC  CLRSS  - FISCRL  75  COMPLET I DNSi 
IF  RSOFDRTE  IS  750630^ 

RND  ENDRTE  IS  BE  TO  7 

RND  PREFIX  ENDRTE  IS  BE  TO  7407-7506'? 

RND  PREFIX  HULL  IS  DE"'' 

RND  PREFIX  HULL  IS  NE  TO  DE6^ 

REPORT  NF6 
SORT  ON  FCLTY 

HERD  1 tDE  CLRSS  - PISCRL  75  COMPET I ONS* 
•BEND 


YOUR  QUERY  HRS  BEEN  RFCEPTED 


FDR  ERCH  QUESTION.  TYPE  IN  D.  T.  DR  B. 


QUERY 

NF*. 

QUESTION 

NO. 

1 . 

HRS 

6 HITS-T 

QUERY 

NF*. 

QUES  T I ON 

NO. 

It'  • 

HRS 

5 HITS-T 

QUERY 

NF*. 

QUESTION 

NO. 

3, 

HRS 

0 HITS 

QUERY 

NF*. 

QUESTION 

NO. 

4. 

HRS 

0 HITS 

w 


4 


i 

I 

i 

1 

) 

t 


i 


FUNriIMG  SUMMARY  - ATLANTIC  FLEET 
DD  CLASS  - FISCAL  75  COMPLETIONS 

REPORT  NFC  NF*001  NOV  12  1975 


YARD 

HULL 

ENIi 

START 

EST 

TOTAL  PER 

HATE 

BATE 

OVHL 

FNIiNG  CENT 

aooo> 

<;i000>  OVHL 

Rcnin 

RH 

nil 

8c!  0 

JUN  75 

JUN  74 

6028 

8028 

521205341 

♦♦♦SUBTOTAL*** 

6028 

6088 

S.I 

nn 

880 

JUN  75 

JAN  75 

4 05:3 

4 058 

521905348 

♦♦♦SUBTOTAL*** 

4 058 

4053 

nn 

889 

OCT  74 

MAR  74 

4894 

4894 

521345343 

nn 

885 

APP  75 

AUG  74 

8586 

3528 

521355344 

3 

nn 

868 

HEC  74 

MAY  74 

4 086 

4 028 

521825342 

♦ ** 

SUBTOTAL*** 

12448 

12448 

3 

nn 

76  5 

APR  75 

AUG  74 

4491 

4491 

038835347 

♦♦♦SUBTOTAL*** 

4491  4491 

♦♦♦♦♦TOTAL**** 

27018  27018 

♦♦♦maximum**** 

8028  8028 

♦♦♦MINIMUM**** 

3528  3528 

♦♦♦♦SIGMA***** 

802  802 
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FUNDING  SUNMRRY  - RTLRNTIC  FLEET 
DUG  CLASS  - FISCAL  75  CDNPETiaNS 


REPORT  NF6  NF*002  NDV  12  1975 


YARD 

HULL 

END 

START 

EST 

TOTAL 

PEP 

DATE 

DATE 

DVHL 

FNDNG 

CENT 

( 1 0 0 0> 

( 1 0 0 0 ) 

DVHL 

RCDID 

c 

DD6  18 

DEC  74 

JAN  74 

5680 

5680 

1 U 0 

046485227 

c 

DDG  1 1 

MAY  75 

JUN  74 

6'S  1 

6*8 1 6 

1 0 0 

046775226 

♦♦♦SUBTOTAL*** 

1 

1£49k 

H 

DDG  5 

DEC  74 

APR  74 

6'?  7 9 

6979 

1 0 0 

046715224 

*** 

SUBTOTAL*** 

■ 

i“.  '3  7 9 

6979 

PH 

DDG  6 

FED  75 

APR  74 

»j7 1 0 

671  0 

1 0 0 

046725225 

PH 

DDG  37 

IAN  75 

MOV  73 

9307 

3307 

1 00 

522315222 

♦♦♦SUFTGTAL*** 

16017  16017 

♦♦♦♦♦TOTAL**** 

35492  55492 

♦ ♦♦MAX  I MUM**** 

9507  9507 

♦♦♦MIN IMUM**** 

5620  5620 

♦♦♦♦ r I GMA***** 

1 1 95  1 1 95 
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CINCLANTFLT 
Historical  Scenario 


I 

Terminal  Session  and 
Report  Samples 


! 

i 

I 

i 

j 

t 

1 

I 
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NShDC  f^im  IMEkCON  \la.2 
DATE  Ig/ie/VS 
TIkE  ie.15.22. 


J 

! 

i 

i 

t 

I 

I 

I 

I 


PLEASE  I or  IN 
LOr-1  N.PUWEWEAVFK  . 1 


80AHHP23.SUP 


COPPAND-  FTL.S0H 
COPPAND-  COPRADE. SHARP 


COPRADE  TIPE:  12. 1ft. 12. 

DALE!  12/12/7S 

SHARP  SUbSYSTEP  ENTEREO 
????  I&IIERY 


YOU  HAVE  SELECTED  THE  INTERACTIVE  (JUERY  OPTION. 
WOULD  YOU  LIKE  AN  EXPLANATION  OE  THE  SYSTEP7-ZA 
????  RFPDEF 


PLEASE  INPUT  REPORT  DEFINITIONS. 

ID  BASE2 
REPORT  NCI 
DhTYPE  IS  RCDID 

PHEAD  SNEW  CONSTRUCTION  nanDAY  REPORTS 

COL  HEAD  1 = SHULLS 

COL  HEAD  2 = SSTART/OATES 

COL  HEAD  3 = SCPSNVOA  T'='£ 

COL  head  a = SYARDS 

COL  HEAD  5 = $P AN /I AbOR / ( DAY S ) £ 

PRINT  HULL.  STARTDAT'^'.  CPSNDATE.  ECITY.  ACTIUAYS 

PRINT  SUP  ACTLDAYS 

PRINT  SI( PA  ACTl DAYS 

PRINT  AVERAf E ACTLDAYS 

PRINT  PAX  ACTLDAYS 

PRINT  PIN  ACTLDAYS 

SEND 


1 
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p,iVvpjtiF; 


FHOhT  OFK-lMriON'  FKKOh  SU^^AhY 


It>  - HASF? 


FFHOKT  - NCI 

NO  FhKOhS  FOUND  - KFFOhT  Dh  »' I M TI  ON  ACCFHTFD 
????  IDUFKY 


YOU  HAVF  SFLFCTFU  THF  INTEhACTIVF  DUFFY  YFl  I ON  . 
WOUl  U YOU  LIHF  AN  FYPLANATION  OF  1 mF  SYSTCN7-NO 


SFLFCT  ONF  OF  THF  FOllOV-'INI^  DATA  bASFS 
IP  I or  I ST  ICS  DOCUNFNT  DATA  FANP 
01  YUFSO  DATA  BANK 
32  NKkS-BASF-2 
??  32 

KFASF  INPUT  OUFKY  CONNANDS 
CUFPY  NCI 

IF  PHFFIX  Hint  IS  SSPN  AND  HISTDATA  IS  OVhl  AND  TYPFOVHI  IS  NC ? 
kFPORT  NCI 

HFAD  1 SSHIP  CLASS  IS  SSbNT 
HEAD  2 SlISTFD  BY  ASCFNDINI  HUl  I T 
SOkT  ON  HULL 
SEND 

YOUk  CUFkY  HAS  BFFN  ACCFPTFD 


FON  FACH  QUESTION.  TYPE  IN  D.  T.  OH  b. 


C'UFHY  NCI.  QUESTION  NO 


1 . HAS 


29  HITS-T 


NEW  CONSThIJCTION  ^AM1AV  REFOKT 


SHIP  Cl  ASS  IS  SSBN 


IISTEO  HY  ASCFNOIM  MUl  I 


REPORT  NCI  NC1U01 


UEC  IS  197S 


START 

DATE 


^ AN 
I APOR 
(DAYS) 


SSBN 

NB? 

AUB 

13 

58 

^ Ah 

01 

6 1 

PTSRH 

051 104410 

SSBN 

NUB 

APR 

01 

59 

^AY 

1 5 

61 

TROT 

051 1 64412 

SSfaN 

N09 

hAh 

06 

62 

NEWS 

051  I 73331 

SSBN 

N10 

OCT 

01 

59 

^Ah 

12 

62 

r-ROT 

051184416 

SSBN 

Nl  1 

DEC 

1 4 

59 

r>  AY 

21 

62 

NEWS 

051 194420 

SSBN 

N I IS 

SEP 

0 1 

60 

APh 

23 

63 

PHOT 

47  4250 

05 1 234424 

SSBN 

N17 

NOV 

01 

60 

JUN 

25 

63 

TROT 

474250 

051244431 

SSBN 

6 1 8 

SEP 

02 

60 

NOV 

12 

62 

NFV.S 

469625 

051254438 

SSBN 

62(? 

FEB 

06 

61 

^AY 

1 8 

64 

PTSRH 

779875 

050624446 

SSBN 

APR 

24 

61 

OCT 

21 

63 

NEWS 

522125 

05074445 1 

SSBN 

S?3 

RAY 

01 

6 1 

OCT 

08 

63 

PHOT 

527750 

050754455 

SSBN 

N2S 

JUL 

1 0 

61 

FCB 

28 

64 

NEWS 

522125 

050774468 

SBN  A27 

OCT  23  I 

61 

JUN  26  1 

64 

NEW  S 

522125 

057013336 

SSBN 

N28 

OFC 

21 

6 I 

JUN 

01 

64 

PROT 

527750 

057023482 

SSBN 

630 

JAN 

22 

62 

JUL 

28 

64 

NEW  S 

660000 

057043346 

SSBN 

631 

RAR 

0 1 

62 

AUC- 

04 

64 

TROT 

660000 

057053352 

SSBN 

633 

RAY 

01 

62 

JUN 

29 

64 

(■  R OT 

660000 

057074476 

SSBN 

6 35 

RAH 

I 4 

62 

OCT  27  64 

NEW  S 

660000 

057093491 

SSBN 

636 

FEB 

0 1 

62 

DEC 

23 

64 

PTSRH 

7 40932 

057 1 03496 

SSBN 

6A0 

DEC 

27 

62 

Aur 

26 

65 

PHOT 

66f000 

057 1 1 3502 

SSBN 

6A1 

NOV 

23 

62 

SEP 

21 

65 

NEW.’S 

660000 

057 1 23508 

SSBN 

6a3 

RAR 

28 

63 

JAN 

21 

66 

PROT 

660000 

057 1 43517 

SSBN 

6 9 4 

JAN 

07 

63 

DEC 

22 

65 

NEWS 

660000 

057  1 53523 

SSBN 

6 45 

APR 

03 

63 

APR 

1 4 

66 

(ROT 

660000 

057 164484 

SSBN 

654 

OCT 

28 

63 

APR 

29 

66 

NEWS 

660000 

057174491 

SSBN 

655 

NOV 

07 

63 

Aur- 

22 

66 

PROT 

660000 

057 184497 

SSBN 

656 

JAN 

06 

64 

JUN 

15 

66 

NEWS 

660000 

057 194503 

SSBN 

657 

RAR 

1 6 

64 

NOV 

28 

66 

NC 

660000 

057204482 

SSBN 

659 

APR 

1 3 

64 

APR 

0 3 

67 

PROT 

660000 

0572245 1 8 

»»*»»TOT Al ***• 


**  * ♦ A(/ERACE  • ♦ • 


* »*PA)'  I KIR  ♦ * » » 


1 


♦••MMKJR**** 


NFW  CONSTKUCTION  KANDAY  REPORT 


SHIP  CLASS  IS  SSPN 


L ISTEO 

BY  ASCEND  I NP 

HUL  L 

REPORT  NCI 

NCI  00  I 

DEC 

HULL 

START 

CRSN 

YARD 

RAN 

DATE 

DATE 

LABOR 

<DAYS) 


•»»»S IOPA*»*»* 


8A9  40 


c 

I 

I 

I 


j 

i 

i 

i 


I 

i 


) 


! 

u 


=<CDID 
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WOULD  YOU  LIKF  TO  SUBMT  ANOTHFR  GlUFRY?-  YFS 


PLFASF  INPUT  QUFRY  COPNANDS 
eUFRY  QSl 

IF  PRFFIX  HULL  IS  FF  AND  HISTUATA  IS  OYHL  AND  TYPFOVHL  IS  NC ? 

RFPORT  NCI 
SORT  ON  HULL 

HEAD  I JSHIP  CLASS  IS  FF$ 

HEAD  2 SLISTED  BY  AESCENDING  HULLS 
HEAD  3 SFIRST  QUESTION  IN  THE  QUERY  SETS 

IF  PREFIX  FULL  IS  ARS  AND  HISTOATA  IS  OVHL  AND  TYPEOVHL  IS  NC? 

REPORT  NCI 

FATAL  ERROR--INVAL ID  SEARCH  ACRONYP  --QUERY  GSI*  QUESTION  0Q2 

ABOVE  QUESTION  WAS  NOT  PROCESSED.  PLEASE  EXAPINE  FOR  SYNTAX  ERROR 
AND  CONTENT.  RE-ENTER  IF  POSSIBLE 

IF  PREFIX  HULL  IS  ARS  AND  TYPEOVHL  IS  N C ? 

REPORT  NCI 
SORT  ON  HULL 

HEAD  1 SSHIP  CLASS  IS  ARSS 

HEAD  2 SORDER  IS  BE  ASCENDINO  HULLS 

HEAD  3 SSECOND  QIUESTION  IS  N THE  QUERY  SETS 

SEND 

YOUR  QUERY  HAS  BEEN  ACCEPTED 


FOREACH  QUESTION.  TYPE  IN  D.  T.  OR  B . 


QUERY 

QSI  . 

QUEST  I ON 

NO. 

1 . HAS 

29 

HITS-T 

QUERY 

QSt  . 

QUEST  I ON 

NO. 

2.  HAS 

0 

HITS  T 
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NEW  CONSTRUCTION  ^ANDAY  REPORT 


SHIP  CLASS  IS  EE 


LISTED  BY  ASCENDING  HULL 


EIRST  QUESTION  IN  THE  QUERY  SET 


REPORT  NCI 


DEC  18  1975 


START 

DATE 


RAN 

LABOR 

(DAYS) 


EE 

1 038 

JUN 

86 

61 

OCT 

21 

63 

0'8 

7 1875 

540363808 

EE 

I 043 

DEC 

03 

62 

EEb 

15 

65 

08 

100000 

540393780 

EE 

1044 

DEC 

03 

62 

AUG 

05 

65 

08 

1 00000 

540403785 

EE 

1047 

AUG 

81 

63 

NOV 

25 

66 

09 

1 10000 

540423813 

EE 

1049 

SEP 

03 

63 

RAY 

23 

67 

09 

1 1 0000 

540443789 

EE 

1056 

DEC 

87 

66 

AUG 

82 

69 

08 

1 1 0000 

5405 1 3794 

EE 

1059 

DEC 

87 

66 

JAN 

03 

70 

08 

1 1 0000 

5405438 1 8 

EE 

I 06  1 

DEC 

87 

66 

RAR 

1 4 

70 

08 

1 1 0000 

540563798 

EE 

1 06  8 

DEC 

27 

66 

JUN 

1 3 

70 

08 

1 1 0000 

540633821 

EE 

1078 

R AR 

89 

68 

JUl 

1 8 

70 

08 

1 1 0000 

540673824 

EE 

1 075 

R-AR 

89 

68 

SEP 

1 9 

70 

08 

1 1 0000 

540703827 

EE 

1 078 

NOV 

86 

68 

APR 

24 

7 1 

08 

1 10000 

800493230 

EE 

I 079 

NOV 

26 

68 

RAY 

88 

7 1 

08 

1 1 0000 

800503833 

EE 

I 080 

JAN 

23 

69 

AUG 

1 4 

7 1 

08 

1 1 0000 

800513801 

EE 

1081 

JAN 

23 

69 

SEP 

1 8 

71 

08 

1 1 0000 

200523804 

EE 

1088 

JUL 

85 

69 

OCT 

30 

7 1 

08 

1 1 0000 

800533807 

EE 

1084 

SEP 

26 

69 

RAR 

1 8 

72 

08 

1 1 0000 

800553810 

EE 

1085 

SEP 

26 

69 

JUL 

22 

78 

08 

1 1 0000 

80056381 3 

EE 

1089 

NOV 

86 

69 

EEB 

17 

73 

08 

1 1 0000 

8006738 1 6 

EE 

1 090 

NOV 

86 

69 

RAH 

31 

73 

08 

1 1 0000 

800683819 

EE 

1091 

DEC 

26 

69 

JUN 

30 

73 

08 

1 1 0000 

800693882 

EE 

1-098 

DEC 

26 

69 

JUL 

28 

73 

08 

1 1 0000 

800703885 

EE 

109  3 

JAN 

26 

70 

NOV 

1 7 

73 

08 

1 1 0000 

8007 1 3828 

EE 

1 094 

APR 

27 

70 

JAN 

86 

7 4 

08 

1 1 0000 

800723831 

EE 

1096 

RAY 

1 I 

70 

JUl 

87 

7 4 

08 

1 1 0000 

800743834 

EE 

1097 

RAY 

1 1 

70 

NOV 

02 

7 4 

,8 

1 1 0000 

800753836 

EEG 

4 

JAN 

06 

64 

APR 

1 4 

67 

BATH 

185000 

046953838 

EEG 

5 

JAN 

06 

64 

JUL 

27 

67 

BATH 

185000 

046983236 

EEC 

6 

JAN 

06 

64 

NOV 

03 

67 

BATH 

125000 

046993240 

* ♦average*** 


* * »RA)f  I RUR  * ♦*  * 


1 EI95^7 


1 PSt'fe'e 
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NEW  construction  NANDAY  REPORT 
SHIP  CLASS  IS  EE 


LISTED  EY  ASCENDING  HULL 
EIRST  QUESTION  IN  THE  QUERY  SET 


REPORT  NCI  QS10t)l 


DEC  19  197S 


LDV  ERR  0003 

overlay  not  EOUND 
DATA  BASE  - BASE2 
HULL  START 

DATE 


NAN 

LABOR 

(DAYS) 


1 M PUP*  »• * 


****SIGPA****» 


1 


WOULD  YOU  LIKE  TO  SUBMT  ANOTHER  OUERY? 


PLEASE  ANSWER  YES  OR  NO-  YES 

PLEASE  INPUT  QUERY  COPPANDS 
QYEUERY  QS2 

IF  PREFIX  HULL  IS  LST  AND  HISTDATA  IS  O^HL  AND  TYPFOVHL  IS  NC ? 
REPORT  NCI 
SORT  ON  HULL 

HEAD  I SSHIP  CLASS  IS  LST$ 

HEAD  2 SORDER  IS  BY  ASCENOINP  HULLS 
HEAD  3 ZFIRST  QUESTION  IN  THE  QUERY  SETS 
HEAD  3 SFIRST  QUESTION  IN  THE  QUERY  SETS 
IF  FCLTY  IS  SSDELETE 

IF  PREFIX  FCLTY  IS  PH  AND  TYPEOVHL  IS  NC ? 

REPORT  NCI 

SORT  ON  STARTOATE 

HEAD  1 SSHIPYARD  IS  PHILAS 

HEAD  2 SWORKLOAD  ASSIONPENT  ALALYSISS 

HEAD  3 SSECOND  QUESTION  IN  THE  QUERY  SETS 

IF  PREFIX  HULL  IS  ARS  AND  HISTDATA  IS  OVHL ? 

REPORT  NAV 

SORT  ON  FCLTY  AND  HULL 

HEAD  1 SSHIP  CLASS  IS  ARSS 

HEAD  2 SORDER  IS  BY  FCLTY  AND  HUl  L S 

HEAD  3 STHRIRD  QUESTION  IN  THE  QUERY  SETS 

SEND 


YOUR  QUERY  HAS  BEEN  ACCEPTED 


FOR  EACH  QUESTION#  TYPE  IN  D»  T.  OR  b. 

QUERY  QS2.  QUESTION  NO.  1.  HAS  9 HITS-T 
QUERY  0S2.  QUESTION  NO.  2.  HAS  A HITS-T 
QUERY  0S2#  QUESTION  NO.  3.  HAS  lA  HITS-T 


NEW  CONSTRUCTION  NANDAY  REPORT 
SHIP  CLASS  IS  LST 
ORDER  IS  BY  ASCENDING  HULL 
FIRST  QUESTION  IN  THE  QUERY  SET 


REPORT  NCI  OS2001 


DEC  12  1975 


START 

DATE 


PAN 

LABOR 

(DAYS) 


LST 

1 179 

JUL 

05 

66 

SEP 

02 

69 

PHILA 

402486 

581793965 

LST 

1 180 

SEP 

06 

66 

JAN 

24 

70 

PHILA 

344757 

200193315 

LST 

1181 

OCT 

03 

66 

JUN 

20 

70 

PHILA 

337020 

200203318 

LST 

1188 

FEB 

03 

69 

JAN 

23 

71 

SD 

225000 

200273320 

LST 

1 192 

NOV 

17 

69 

SEP 

01 

71 

1 1 

225000 

200313323 

LST 

1193 

JAN 

30 

70 

OCT 

16 

71 

1 1 

225000 

200323969 

LST 

1 194 

PAR 

06 

70 

DEC 

1 8 

71 

1 1 

225000 

200333972 

LST 

1196 

AUG 

03 

70 

APR 

08 

72 

I 1 

225000 

202223975 

LST 

1 197 

SEP 

08 

70 

PAY 

27 

72 

1 I 

225000 

202233978 

*****TOTAL**** 


♦♦♦•AVERAGE*** 


♦♦♦PAX IPUP**** 


♦♦♦PIMPUP**** 


243A2ft3 


274147  4» 


A02A86 


225000 


♦♦♦♦SIGPA***** 


F 


NEW  CONSTRUCTION  RANDAY  REPORT 


SHIPYARD  IS  PHI 
WORKLOAD  ASSIGNMENT 
SECOND  QUESTION  IN  THE 

REPORT  NCI  osseea 

HULL  START  CMSN 

DATE  DATE 


DDG 

44 

NOV 

01 

57 

OCT 

19 

61 

LPH 

7 

NOV 

01 

60 

SEP 

30 

63 

LPH 

9 

APR 

02 

62 

JAN 

16 

65 

LST 

1 1 79 

JUL 

05 

66 

SEP 

02 

69 

1ST 

1 180 

SEP 

06 

66 

JAN 

24 

70 

LST 

118  1 

OCT 

03 

66 

JUN 

20 

70 

ALALYSIS 
QUERY  SET 

DEC  12  1975 


YARD 

NAN 

LABOR 

(DAYS) 

RCDID 

PHILA 

526843909 

PHILA 

528025 

073523288 

PHILA 

499375 

07  1783294 

PHILA 

402486 

581793965 

PHILA 

344757 

200193315 

PHILA 

337020 

200203318 

♦♦♦**total»*»* 


1 

{ 


♦♦♦♦AVERAGE*** 


♦♦♦MAXINUN**** 


♦♦♦MMNUN**** 


****Sir-NA***** 


21  1 1 Af.3 


A22333 


52K025 


337020 


78481 


DATA  BASE  - BASE2 


i 
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SHIPYARD  WORK  ASSIGNRENT  REPORT 
SHIP  CLASS  IS  ARS 
ORDER  IS  BY  FCLTY  AND  HULL 


THIRD 

QUESTION 

IN  THE 

QUERY  SET 

REPORT 

NAV  GSB003 

DEC  12  1975 

FCLTY 

HULL 

START 

END 

TYPE 

KAN 

DATE 

DATE 

OVHL 

DAYS 

JACK 

ARS 

6 

JUN 

08 

70 

JAN 

17 

71 

RO 

7215 

JACK 

ARS 

6 

JUN 

1 5 

75 

NOV 

1 7 

75 

RO 

11315 

PHILA 

ARS 

40 

FEB 

10 

7 1 

JUL 

02 

71 

RO 

21022 

03 

ARS 

43 

AUG 

1 4 

62 

OCT 

26 

62 

RO 

2564 

03 

ARS 

6 

PAR 

07 

61 

JUN 

16 

61 

RO 

0A 

ARS 

40 

SEP 

10 

63 

JAN 

13 

64 

RO 

4650 

05 

ARS 

40 

FEB 

13 

67 

JUN 

20 

67 

RO 

7390 

05 

ARS 

40 

SEP 

24 

74 

PAR 

18 

75 

RO 

1 5455 

05 

ARS 

41 

SEP 

13 

68 

FEB 

1 7 

69 

RO 

7340 

05 

ARS 

41 

JUN 

16 

72 

JAN 

08 

73 

RO 

9255 

05 

ARS 

43 

JAN 

03 

66 

APR 

12 

66 

RO 

5590 

05 

ARS 

43 

JUN 

27 

69 

OCT 

30 

69 

RO 

10517 

05 

ARS 

43 

APR 

04 

73 

OCT 

24 

73 

RO 

12250 

05 

ARS 

6 

PAY 

20 

63 

AUG 

20 

63 

RO 

2480 

06 

ARS 

41 

APR 

1 6 

65 

AUG 

13 

65 

RO 

8510 

10 

ARS 

6 

SFP 

20 

66 

APR 

28 

67 

RO 

9600 

♦♦♦♦♦total**** 

135153 
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WOULD  YOU  LIKE  TO  SUBMT  ANOTHER  QUERY?-  YES 


QUERY  RUN  ABORTED  IN  ROUTINE  LT 
REPDEF3  - OPEN  OLD  ON  A NON-EXISTING  FILE 
SOURCE  LINE  NUPBFR  00556 
fatal  COBOL  ERROR  - RUN  TERMINATED 

WOULD  YOU  LIKE  TO  SUBMT  ANOTHER  QUERY?-  YES 

PLEASE  INPUT  QUERY  COMMANDS 
QUERY  QS3 

IF  PREFIX  HULL  IS  AKS  AND  HISTDATA  IS  OVHL ? 

REPORT  NAV 

SORT  ON  STARTDATE 

HEAD  1 SSHIP  CLASS  IS  ARS$ 

HEAD  2 SOVERHAUL  HISTORY  ORDERED  BY  START  DATES 

HEAD  3 SADDITIONAL  INFORMATION  IS  REQUIRED  AT  QUERY  TIMES 

PRINT  AVERAGE  ACTLOAYS 

PRINT  MAX  ACTLDAYS 

PRINT  MIN  ACTLDAYS 

PRINT  SIGMA  ACTLDAYS 

SEND 

YOUR  OUFRY  HAS  BEEN  ACCEPTED 


FOR  EACH  QUESTION^  TYPE  IN  D>  T>  OR  B. 

QUERY  QS3.  QUESTION  NO.  1.  HAS  16  HITS-T 
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SHIPYARD  WORK  ASSIGNMENT  REPORT 
SHIP  CLASS  IS  ARS 

OVERHAUL  HISTORY  ORDERED  BY  START  DATE 


ADDITIONAL  INFORMATION  IS  REQUIRED  AT  QUERY  TIME 


REPORT 

NAV  OS3001 

DEC  12  1975 

FCLTY 

HULL 

start 

END 

TYPE 

MAN 

DATE 

DATE 

OVHL 

DAYS 

03 

ARS 

6 

MAR 

07 

61 

JUN 

1 6 

61 

RO 

03 

ARS 

43 

AUG 

14 

62 

OCT 

26 

62 

RO 

2564 

05 

ARS 

6 

MAY 

20 

63 

AUG 

20 

63 

RO 

2480 

04 

ARS 

40 

SEP 

10 

63 

JAN 

13 

64 

RO 

4650 

06 

ARS 

41 

APR 

1 6 

65 

AUG 

13 

65 

RO 

8510 

05 

ARS 

43 

JAN 

03 

66 

APR 

12 

66 

RO 

5590 

10 

ARS 

6 

SEP 

20 

66 

APR 

28 

67 

RO 

9600 

05 

ARS 

40 

FEB 

13 

67 

JUN 

20 

67 

RO 

7390 

05 

ARS 

41 

SEP 

13 

68 

FEB 

17 

69 

RO 

7340 

05 

ARS 

43 

JUN 

27 

69 

OCT 

30 

69 

RO 

10517 

JACK 

ARS 

6 

JUN 

08 

70 

JAN 

I 7 

7 1 

RO 

7215 

PHILA 

ARS 

40 

FEB 

10 

7 1 

JUL 

02 

7 1 

RO 

21022 

05 

ARS 

4 1 

JUN 

16 

72 

JAN 

08 

73 

RO 

9255 

05 

ARS 

43 

APR 

04 

73 

OCT 

24 

73 

RO 

1 2250 

5 

ARS 

40 

SEP 

24 

74 

MAR 

1 8 

75 

RO 

15455 

JACK 

ARS 

6 

JUN 

I 5 

75 

NOV 

17 

75 

RO 

11315 

♦♦♦♦♦total**** 

135 153 

♦♦♦♦AVERAGE*** 

9Q1Q 

♦♦♦MAXIMUM**** 

2102? 

♦♦♦MINIMUM**** 

2480 

4A77 
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WOUID  YOU  lihf:  to  submt  anothek  query?-  yes 


PLEASE  INPUT  QUERY  CONNANDS 
QUERY  QS4 

IF  PREFIX  HULL  IS  AkS  AND  HISTUATA  IS  OVHL? 

REPORT  NAV 

SORT  ON  HULL  AND  STARTDATE 
HEAD  1 SSHIP  CLASS  IS  ARSS 
head  9 SHI  STORY  OF  EACH  SHIPS 

HEAD  3 STHE  INFORNATION  PROCESSING  POWER  OF  NAVLISS 

PRINT  SUBTOTAL  ACTLDAYS  ON  HULL 

SFND 


YOUR  QUERY  HAS  BEEN  ACCEPTED 


FOR  EACH  QUESTION. 


TYPE  IN  D.  T.  OR  B. 


I > 


QUERY  QS4.  QUESTION  NO 


HAS 


16  HITS-T 


j 

t 

•;  SHIPYARD  V.'OKK  ASSIGNNENT  REPORT 

SHIP  CLASS  IS  ARS 
HISTORY  OF  EACH  SHIP 


THE  I NFOHPATl ON  PROCESSING  POWER  OF  NAVL I S 


REPORT 

NAV 

QS4001 

DEC  12  1975 

FCLTY 

HULL 

START 

END 

TYPE 

NAN 

DATE 

DATE 

OVHL 

DAYS 

04 

ARS 

40 

SEP 

1 0 

63 

JAN 

1 3 

64 

RO 

4650 

05 

ARS 

40 

FEB 

1 3 

67 

JUN 

20 

67 

RO 

7390 

PHI  1 A 

ARS 

40 

FEB 

1 0 

7 1 

JUL 

02 

7 1 

RO 

2 1 022 

05 

ARS 

40 

SEP 

24 

74 

PAR 

18 

75 

RO 

1 5455 

♦♦♦SUBTOTAL*** 

485  1 7 

06 

ARS 

41 

APR 

16 

65 

AUG 

1 3 

65 

RO 

85  10 

05 

ARS 

41 

SEP 

13 

6P 

FEB 

I 7 

69 

RO 

7340 

5 

ARS 

41 

JU^ 

1 6 

72 

JAN 

08 

73 

RO 

9255 

♦ ♦♦SIJBTOTAL*** 


P51  OS 


03 

ARS 

43 

AUG 

1 4 

62 

OCT 

26 

62 

RO 

2564 

05 

ARS 

43 

JAN 

03 

66 

APR 

12 

66 

RO 

5590 

05 

ARS 

43 

JUN 

27 

69 

OCT 

30 

69 

RO 

10517 

05 

ARS 

43 

APR 

04 

73 

OCT 

24 

73 

RO 

12250 

♦♦♦SUBTOTAL*** 

3092  1 


03 

ARS  6 

PAR 

07 

61 

JUN 

16 

61 

RO 

05 

ARS  6 

NAY 

20 

63 

Aur 

20 

63 

RO 

2480 

10 

ARS  6 

SEP 

20 

66 

APR 

28 

67 

RO 

9600 

JACK 

ARS  6 

JUN 

08 

70 

JAN 

1 7 

7 1 

RO 

721  5 

JACK 

ARS  6 

JUN 

1 5 

75 

NOV 

1 7 

75 

RO 

11315 

i 


♦♦♦SUP-TOTAl  ♦♦♦ 


30610 
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■! 

! 


> ( 

( 


SHIPYARD  WORK  ASSIGNPEM  REPORT 
SHIP  CLASS  IS  ARS 
HISTORY  OF  EACH  SHIP 

THE  INFORPATION  PROCESSING  POWER  OF  NAVLIS 
REPORT  NAV  QS4001 

FCLTY  HULL  START  FND  TYPE  PAN 

DATE  DATE  OV/HL  DAYS 

♦*»**70TAL**** 


135153 


i 

< • 

i 

% 

1 » 


i ' 

i , 
! 

I 


t 


DEC  12  1975 
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WOULD  YOU  LIKE  TO  SUBMT  ANOTHER  QUERY  ?- 
DATA  BASE  - BASES  YES 

PLEASE  INPUT  QUERY  CORKANDS 
QUERY  QS6 

IF  SHIP  IS  BELKNAP? 

SORT  ON  ASOFDATE 

HEAD  1 $THE  POWER  OF  NAVLIS  TO  AUDITS 
HEAD  S SFULL  DISCLOSURE  ON  THE  BELKNAPS 

HEAD  3 SDERONSTRAT I ON  OF  THE  INTEGRATION  OF  THE  ARCHITECTURES 
SFND 

YOUR  QUERY  HAS  BEEN  ACCEPTED 


FOR  EACH  QUESTION.  TYPE  IN  D.  T.  OR  B. 


QUERY  0S6.  QUESTION  NO 


1 . HAS 


9 HITS-T 


r 


THE  POWER  OF  NAVLIS  TO  AUDIT 
FULL  DISCLOSURE  ON  THE  BELKNAP 
DEMONSTRATION  OF  THE  INTEGRATION  F THE  ARCHITECTLIRF 
REPORT  DFT  OS6001  DEC  12  1975 


ACTLDAYSJ  288125 
ASOFDATE:  611002 
CDR:  HENCK 
CMSNDATE:  641107 
DURATNt  3.0 
ENDATE!  641104 
FCLTYJ  BATH 
HISTDATA!  OVHL 
HULL:  CG  26 
INTRVL:  33.0 
NAVY:  NAVSEA 
PROC/DATE:  751114 
RCDID:  527013928 
SHIP:  BELKNAP 
STARTDATE:  611002 
TYCOM:  2 
TYPEOVHL:  NC 
UIC:  52701 


ACTLDAYS:  7960 

ASOFDATE:  641109 
CDR:  HENCK 
CMSNDATE:  641107 
DURATN:  4.0 

ENDATE:  650805 
FCLTY:  BSN 
HISTDATA:  OVHL 

HULL:  CG  26 
INTRVL:  33.0 
NAVY:  NAVSEA 
PROC/DATE:  751114 
RCDID:  527013929 
SHIP:  BELKNAP 
STARTDATE:  641109 
TYCOM  2 
TYPEOVHL:  FO 
UIC:  52701 


! 


s 

? 

i 


1 


THE  POWER  OF  NAVLIS  TO  AUDIT 
FULL  DISCLOSURE  ON  THE  BELKNAP 
DEMONSTRATION  OF  THE  INTEGRATION  OF  THE  ARCHITECTURE 
REPORT  DFT  QS6001  DEC  12  1975 


ACTLDAYSt  18398 
ASOFDATE:  650730 
CDRi  HENCK 
CMSNDATEl  6A1I07 
DURATNl  4.0 
ENDATE!  651126 
FCLTYI  NORVA 
HlSTDATAs  OVHL 
HULL:  CG  L6 
INTRVL:  33.0 
NAVY:  NAVSEA 
PROC/DATE:  751114 
RCDIDI  527013930 
SHIP:  BELKNAP 
STARTDATE:  650730 
YC  ON : 2 
YPEOVHL:  PS 
UIC:  52701 


ACTLDAYS:  9277 

ASOFDATE:  670327 
CDR:  HENCK 
CMSNDATE:  641107 
DURATN:  4.0 

ENDATE:  670705 
FCLTY:  NORVA 
HISTOATA:  OVHL 
HOMEPORT:  NORVA 
HULL:  CG  26 
INTRVL:  37.0 
NAVY:  NAVSEA 
PR OC /date:  751114 
RCDID:  527013931 
SHIP:  BELKNAP 
STARTDATE:  670327 
TYCOM:  2 
TYPEOVHL:  RA 
UIC:  52701 


ACTLDAYS:  A5A28 

ASOFDATEl  680904 
CDR:  HENCK 
CRSNDATE:  641 107 
I DURATNS  4.0 

i ENDATE:  690404 

FCLTY!  NORVA  | 

HISTDATAl  OVHL 

HOREPORT:  NORVA  i 

HULl  CG  26  i 

INTRVLt  37.0 
NAVY:  NAVSEA 
PROC/DATE!  751114 

' RCDIDs  527013932 

SHIP:  BELKNAP  ’ 

STARTDATF:  680904 

TYCOM  2 

TYPFOVHLj  RO 

UICJ  52701 


! 

ACTLDAYSt  62194 
ASOFDATE:  720327 
CDRl  HENCK 
CPSNDATE:  641107 
DURATN:  4.0 

FNDATE!  721113 

, FCLTY:  NORVA 

, HISTDATA:  OVHL 

HOPEPORTl  NORVA 

, HULL:  CG  26 

INTRVL:  37.0 
NAVY!  NAVSEA 
PROC/DATE:  751114 

i RCDID:  527013933 

i SHIP:  BELKNAP 

j STARTDATF:  720327 

I TYCOP!  2 

j TYPFOVHL:  RO 

i UIC:  52701 

i 
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THE  POWER  OE  NAVLIS  TO  AUDIT 

FULL  DISCLOSURE  ON  THE  BELKNAP 

DEMONSTRATION  OF  THE  INTEGRATION  OF  THE  ARCHITECTURE 
DATA  BASE  - BASE2 
DFT  REPORT  DEFINITION  NOT  FOUND 

REPORT  DFT  OS600I 


ASOFDATE:  750T31 
CDR:  SHARP 
CNTYRPLN:  500 

ENDATE;  7802 
ESTCNTYRQt  500 
FCLTYj  C 

FNDACTVTY;  76AFR 
HULL*  CG  26 
NAVY!  CINCLANTFLT 
ROC /DATE!  751  I M 
RCDIDi  527015507 
SHIP!  BELKNAP 
STARTOATE!  7702 
TYCOM!  2 
UIC!  52701 


ASOFDATE!  750B31 
CDR!  SHARP 
CNTYRPLN:  600 

ENDATE!  7802 
ESTCNTYRG:  600 

FCLTY!  C 

FNDACTVTY!  76AFR 
HULL!  CG  26 
NAVY:  CINCLANTFLT 
PROC/DATE!  751209 
RCDID:  527015663 
SHIP!  BELKNAP 
STARTDATE:  7702 
TYCOM:  2 
UIC!  52701 


THE  POWER  OF  NAVLIS  TO  AUDIT 


FULL  DISCLOSURE  ON  THE  BELKNAP 


DEMONSTRATION  OF  THE  INTEGRATION  OF  THE  ARCHITECTURE 


REPORT  DFT  QS6001 


DEC  le  1975 


ASOFDATEs  770415 
ASSOC;  DLG 
CDR:  WARD 
DURATN;  9.0 
HULL;  CG  26 
INTRVL:  37.0 
NAVY:  CINCLANTFLT 
PROC/DATE:  751114 
RCDIDt  527010014 
SCDACTVTY:  PROJ 
SHIP!  BELKNAP 
STARTDATE;  7512 
UIC:  52701 
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WOULD  YOU  LIKE  TO  SUBK'IT  ANOTHER  QUERY?-  YES 


PLEASE  INPUT  QUERY  CONNANDS 
QUERY  SET 

IF  FNDACTVTY  IS  73BDGT  OR  7ABDC-T  OR  75BDf-T  OR  76BDGT? 

REPORT  S06 

SORT  ON  FNDACTVTY  ANDHULL  HULL 

PR’NT  SUBTOTAL  BDGTLDAYS>  BDGTLNNY>  BDGTNNNY/  BDGTUCOST  ON  FNDACTVTY 
PRINT  SUN  ON 

HEAD  1 STHE  POWER  OF  NAVLIS  TO  RECONCILES 
HEAD  2 SWHAT  WE  SI  AD  WE  WERE  GOINT  TO  DOS 
SEND 

YOUR  GUER  HAS  BEEN  ACCEPTED 


FOR  EACH  QUESTION#  TYPE  IN  D»  T#  OR  B. 


QUERY  SET#  QUESTION  NO 


I # HAS 


26A  HITS-T 


APPOhT 1 ONPFNT 


r 


THE  POWER  OF  NAVLIS  TO  RECONCILE 
WHAT  WE  SI  AD  WE  WERE  COINT  TO  DO 

REPORT  S06  SED001  DEC  IP  1975 


HULL  KAN 

LABOR 

KATL 

UNIT 

HOURS 

FUND 

FUND 

COST 

RCDI  D 

AD  38 

1615 

325 

1 940 

058372598 

AR  28 

3516 

688 

4204 

046462605 

ARC  2 

2503 

496 

2999 

755622607 

ARS  43 

1 049 

222 

1271 

025382606 

AS  16 

2805 

695 

3500 

046262581 

AS  18 

2525 

448 

2973 

046282582 

ASR  1 4 

513 

92 

605 

047132583 

CC  10 

7906 

1 698 

9604 

036232584 

CG  16 

2888 

591 

3479 

526872585 

CC-  28 

3289 

589 

3878 

527032586 

CG  32 

327  1 

585 

3856 

527072587 

CV  6 0 

1 8277 

3739 

22016 

033602573 

DD  822 

2884 

515 

3399 

521222613 

DD  841 

I 697 

527 

2224 

521412588 

DD  850 

2606 

522 

3 1 28 

52 1 502589 

DD  864 

2549 

522 

3071 

52164261 4 

DD  865 

3047 

545 

3592 

521652590 

DO  67  1 

2828 

566 

3394 

521712591 

DD  878 

3047 

545 

3592 

521782592 

DD  883 

2639 

528 

3 1 67 

521832593 

DD  9 42 

2965 

538 

3503 

522012594 

DD  9 44 

27  1 8 

560 

3278 

522032595 

FF  1043 

2155 

416 

2571 

540392596 

FFG  4 

1901 

366 

2267 

046952597 

LPD  4 

3574 

763 

4337 

071752599 

LSD  32 

3695 

786 

4483 

03 1 322600 

LSD  34 

3860 

824 

4684 

031342601 

KSC  198 

259 

43 

302 

164612624 

KSC  199 

259 

43 

302 

1 64622625 

KSC  205 

197 

41 

238 

1 64682626 

KSC  206 

197 

41 

238 

164692627 

KSC  207 

208 

41 

249 

164702628 

KSO  427 

492 

81 

573 

079572615 

KSO  429 

539 

89 

628 

079592616 

LDV  ERR  0003 

OVERLAY  NOT  FOUND 

DATA  BASE  - BASE2 

KSO  431 

354 

89 

443 

079612617 

KSO  433 

831 

152 

983 

079632608 

KSO  439 

417 

81 

498 

079692618 

KSO  441 

513 

103 

616 

079712619 

KSO  445 

470 

86 

556 

079752609 

KSO  446 

47  0 

86 

556 

079762610 

KSO  449 

470 

86 

556 

07979261 1 

KSO  455 

393 

81 

474 

079852620 

KSO  456 

470 

86 

556 

079862612 

KSO  464 

492 

81 

57  3 

079942621 

KSO  489 

417 

81 

498 

081472622 

KSO  492 

492 

81 

573 

081502623 

rC  101 

381 

7 I 

452 

200942604 

PG  9 4 

381 

71 

452 

200872602 

358 


APPORTIONMENT 


THE  POWER  OF 

NAVLIS 

TO  RECONCILE 

WHAT  WE  SIAD 

WE  WERE 

GOINT  TO  DO 

REPORT  S06 

SET001 

DEC  12  1975 

HULL 

MAN 

LABOR 

MATL 

UNIT 

HOURS 

FUND 

FUND 

COST 

RCDID 

PG  99 

381 

71 

452 

200922603 

SS  351 

3545 

609 

4154 

054512574 

SSBN  602 

29552 

5609 

35161 

051 102629 

SSBN  608 

26532 

5609 

32141 

051  162630 

SSBN  609 

25374 

5408 

30782 

051  172631 

SSN  571 

17316 

3848 

21164 

055912575 

SSN  597 

20603 

3498 

24101 

050602576 

SSN  607 

15809 

3498 

19307 

051 152577 

SSN  638 

1 1 053 

2456 

1 3509 

051312578 

SSN  6A6 

12065 

2826 

1 4891 

051332579 

SSN  649 

12672 

2768 

15440 

051362580 

♦♦♦SUBTOTAL*** 

0 

275926  56507 

332433 

AD  18 

1 4341 

1750 

416 

2 1 66 

046382650 

AE  21 

1753 

607 

2360 

088212674 

AE  27 

1795 

617 

2412 

058392658 

AF  58 

18883 

2096 

402 

2498 

015972639 

AFS  6 

27  16 

607 

3323 

201 1 62659 

AO  147 

3483 

967 

4450 

059072660 

AO  98 

4263 

891 

5154 

048482652 

Report  abbreviated  for  this  appendix. 
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1 


I 

} 

' NSPPr  f.7PP  IMTFprOM 

■ PATF  lP/l*=./7^ 

TIIVF  I3.P-9..7A. 

PLFA'F  LOrlM 

: LOriN.Pl'VFVFAV'FR.  1 t P . FI 'P 

COmmaNP-  FTL.PPP 
rOMMAR'P-  rOMPAPF.  5HAPP 


COMPAPF  TImF:  17. 

PATF:  1P/1P/-JP 

FHARP  Pl'PFYFTFM  FMTFPFP 
•>???  in 'FRY 

PLFAFF  INPI'T  PUFRY  rOMMANPR 
PI'FRY  PP7 

IF  ASOFPATF  IS  7AP771  ANP  SI'FFIX  F\ipACTUTY  IS  AFP  A\'P  PPRRix  RMppjF 
I S LF  TO  7S7APA? 

PRINT  HULL  ANP  SHIP 

HFAD  1 FSHIPS  THAT  FNP  UITHIN  THF  FIRST  '’//iSS 
*FNP 

YOI'P  Ol'FPY  HAS  PFFN  AfPFPTFP 


FOP  FACH  ei'FSTION.  TYPF  IN  P,  7.  np  P. 

Pl'FPY  PPFSTION  NO.  1,  HAS  P HITS-T 


1 


SHIP?  THAT  FND  VITHIM  THF  FIFST  T/.AC 


I ; 


PFPOPT  DFT 


PFC  197“; 


HI 'LL: 

LSD  ?9 

SHIP! 

PLYMOUTH  POCK 

HULL! 

LPD  lA 

SHIP: 

TRFNTON 

HULL! 

Pr-  BA 

SHIP! 

ANTFLOPF 

HI 'LL! 

pr-  B7 

SHIP! 

PFADY 

HULL! 

LST  1IB1 

SHIP! 

SUMTFR 

V'OI'Lf)  YOl'  LIKF  TO  SUBMIT  ANOTHFP  OI'FPY?- 
LPV  FPP  PI0P3 
OVFPLAY  NOT  FOUNP 
DATA  BASF  - BASF? 

DFT  RFPOPT  DFFINITION  NOT  FO|iND  NO 

????  IPUFRY 


YOU  HAVF  SFLFCTFD  THF  INTFRACTIV/F  PUFPY  OPTION. 
V'OULD  YOU  LIKF  AN  FXPLANATION  OF  THF  RYSTFM?-Nr 


SFLFCT  ONE  OF  THF  FOLLOV'INP  DATA  BASES 
IB  LODISTICS  DOCUMENT  DATA  BANK 
31  YURSO  DATA  BANK 
3P  MKRS-BASF-? 

? ? TA 


USFP  ABORT 
????  PFPDFF 


PLFASF  INPUT  REPORT  DFEINITIONS. 

ID  BASF? 

REPORT  PP3 
DPTYPF  IS  PCDID 

MHFAD  fFUNDINP  PPOFIl.F  PFPOPTf 
COL  HFAD  I = THULL* 

COL  HFAD  ? = FAS  OE/OATFS 
COL  HEAD  3 = JPP I OP/YRFNP/ (1 PPPF ) 5 
COL  HFAD  A = rCNTYP/PLAN/( 1 DPP) F 
COL  HFAD  S = «CNTYP/ENP/( 1 PPP)* 

COL  HEAP  A = FFST  CNTYP/PPMTT 

PRINT  HULL  ASOFDATF  PYPYPFNP,  CNTYPPLN,  CNTYPFNP/  FSTCNTYRPT 
PRINT  subtotal  PRYPYRFND,  CNTYPPLN,  CNTYPFNP,  FFTCNTYPPT  ON  Hint 
FFND 
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RFPOPT  DFFINITION  FRFOR  RUMMAPY 


j 


in  - BASF? 


REPORT  - 003 

NO  FRPORS  FOUND  - RFPOPT  DFFINITION  ACCFPTFD 
? ? ? ? 

FX  ID=  CADC  PFN=DATADFFF ILF 

FX  CY=  001  00001 7S1  PPn?  J000A.3P  /DAY 

I Ol'FPY 


YOU  HAVF  SFLFCTFD  THF  INTFRACTn/F  DUFRY  OPTION. 
WOULD  YOU  LIKF  AN  FXPLANATION  OF  THF  FY?TFM?-NO 


SFLFCT  ONE  OF  THF  FOLLOI.'IND  DATA  PA?FS 
IP  LOP  I ST  I CF  DOP.UV,fnt  DATA  PANW 

31  YUR50  DATA  PANW 

32  MKPS-PASF-2 
? ? 32 


PLEAFF  INPUT  OmFPY  DOMYANDS 
DUERY  00A 

IF  HULL  IS  LSD  29  OF  I.PD  1^  OP  PP  RA  OP  PP  P7  OP  LFT  llRl 
AND  FNDACTVTY 
AND  FNDACTVTY 

AND  SUFFIX  FNDACTVTY  I COP  OF  CFY  OP  FRA  OP  AFP? 

REPORT  003 

HFAD  1 FAFR  AFOFJI'l  Y FY7S  FHIPS  COMPLFTINP  PPIOP  TO  ATH  DUAOTPpj 

FORT  ON  hull  AND  ASOFDATF 

FFND 

YOUP  OUFPY  HAS  PFFN  ACCFPTFD 


. FOP  FAPH  OI.ifFTION,  TYPF  IN  D.  T,  OP  P. 

ruFPY  00A,  OUFSTION  no.  1,  HAP  70  HITS-T 

i 

I 

I 


I 


364 


FHNDlNr  PpnflLF  FFPOPT 


AFP  ASOFJULY  FY7S  SHIPS  COMPLFTIMF  PFIOP  TO  4TH  PlipPTFP 


PFPORT 

Plf13  0CI4PD' 

DF0  IS  I97S 

HULL 

AS 

; OF 

PPIOP 

CMYP 

CNTYP 

FST  CNTYP 

DATF 

YPFND 

PI  AN' 

FND 

FONT 

< 1 0001 

( 1 ) 

( 1 000 ) 

FCDID 

LPP 

1 A 

Jl’L 

31 

7 4 

7A(^ 

740 

070004345 

LPD 

1 4 

ADD 

31 

74 

740 

07P0041 97 

LPD 

1 A 

SFP 

30 

74 

7AP 

7 

740 

07P00030? 

LPD 

1 A 

OCT 

31 

74 

0 

7AO 

1F7 

740 

070000471 

LPD 

1 A 

NOV 

30 

74 

1P7 

7f  0 

07P000A47 

LPn 

1 A 

DFC 

31 

74 

IP7 

740 

07P000P4P 

LPD 

I 4 

JAN 

31 

7S 

IP7 

3R0 

07P001 049 

LPD 

1 4 

FFP 

?8 

75 

55(^ 

?40 

540 

07P001 314 

LPD 

1 4 

HAP 

31 

75 

440 

S50 

07P004P99 

LPD 

1 4 

APR 

30 

75 

0 

55P< 

440 

SC0 

07P004097 

LPD 

1 4 

MAY 

31 

75 

440 

440 

440 

07P00449P 

LPD 

I 4 

JDN 

30 

75 

41  A 

4 I 4 

41  4 

07P005303 

LPD 

1 4 

JI'L 

31 

7*=- 

41  A 

7744 

490S 

7344 

07P005437 

LPD 

1 4 

Al'C 

31 

75 

41  f 

4?9I 

S40S 

4P9  I 

07P004^9P 

.♦*C(ipTOTAL*** 

03?  P03PI  I 304  1 

PI  09  1 

LSD 

?9 

JI'L 

31 

7^ 

500 

071094747 

LSD 

?9 

Al'C 

31 

74 

A00 

071094199 

LSD 

?9 

SFP 

30 

74 

7 

500 

071 090704 

L SD 

?9 

OCT 

31 

74 

4(^(3 

191 

500 

071090474 

LSD 

?9 

NOV 

30 

74 

40P 

191 

500 

071090549 

LSD 

?9 

DFC 

31 

74 

191 

500 

071090950 

LSD 

?9 

JAN 

31 

75 

0 

4(^0 

191 

400 

071091051 

LSD 

P9 

FFP 

PR 

75 

47*^ 

475 

47*^ 

07*091 719 

LSD 

?9 

NAP 

31 

75 

475 

475 

475 

071094901 

LSD 

?9 

APR 

30 

75 

51 

51  5 

5! 

07109509R 

LSD 

P9 

MAY 

31 

75 

570* 

5 70 

^70 

071094700 

LSD 

?9 

JI'N 

30 

75 

570 

^ 70 

570 

071095705 

LSD 

?9 

Jt'L 

3 1 

75 

530 

5757 

507^ 

5797 

071095477 

LSD 

?9 

Al'C 

31 

75 

530 

54/;0 

'=075 

5450 

071095597 

♦ **.51'FT^TAL*«* 

1050  1?1<9  1'*755 

1 775P 

LST  llRl 

JI'L  31  7A 

P'^A 

pAA 

PP(>?PA3A9 

LST  llRl 

Al'C  3 1 7/1 

PSA 

PAA 

PPPPRAPRl 

LRT  IIPI 

'■pp  3?  7 A 

PAA 

PAA 

PPPP003PA 

LST  I IRI 

OCT  31  7A 

PAA 

pAA 

POPPOPATA 

DATA  PA 
L'^T  ItPI 

'T  - PASF? 
NOV  30  lA 

PAA 

IP! 

PAA 

pppppVasi 

LST  IIPI 

DFC  •’1  7 A 

PAA 

1 P 1 

AAR 

PRPPPRRAP 

LST  MPI 

JAN  31  75 

3AA 

?3A 

3 aa 

PPPPPl PA3 

I 


f 


i 

I 

i 

i 


rUNDINP  PFOFILF  PFPOPT 


AFP  AFOFJI'IY  FY7P  SHIPS  COMPLFTINr  PPIOR  TO  ^TH  PPAPTFP 
PFPOPT  003  00/1001  ppr  IS  197S 


HULL 

AS 

; OF 

PFIOP 

CNTYP 

CNTYP 

FST  CNTYP 

PATF 

YFFMP 

PLAN 

FNP 

PPMT 

( 1 000) 

( 1000) 

< 1 000) 

proio 

LST 

llRl 

FFP 

PR 

A90 

*80 

*90 

P00P01 3P0 

LST 

1 ISl 

MAP 

31 

7S 

*90 

*80 

*90 

00000*903 

LST 

11B1 

APP 

30 

7*^ 

*90 

*80 

*90 

00000SI00 

LST 

IIPI 

MAY 

31 

7S 

*80 

*80 

*80 

00000*700 

LST 

1 IPl 

JI'N 

30 

7S 

*80 

*80 

*80 

00000S307 

LST 

IIPI 

JPL 

31 

7S 

A80 

* A30 

P9S0 

**30 

00000S*38 

LST 

1181 

Atm 

31 

7S 

*80 

3RS  1 

3797 

38  SI 

P0000SS9* 

♦♦♦SPPTnTAL*** 


1 3*0 

1 3*03 

1 07*S 

1 399  7 

pr- 

8* 

JI'L 

31 

7/) 

PR 

P8 

1 ?<;R'i434? 

pr- 

8* 

Alip 

31 

7^ 

08 

?8 

1?5PS4191 

pp 

8* 

SFP 

30 

74 

P8 

pR 

1 

pp 

8* 

OCT 

31 

74 

08 

pp 

1 

pp 

8* 

NOV' 

30 

74 

?8 

P8 

1 p5^5ipif,A(^ 

pp- 

86 

DFC 

31 

74 

PR 

P8 

1 ?SRRp«R4? 

pp 

8* 

JAN 

3 1 

75 

?8 

PR 

I P5F5  1 pi43 

pp 

8* 

FFP 

?8 

75 

?8 

?8 

1?*=;8P1313 

pp 

8* 

MAP 

31 

75 

?8 

PF. 

l??PP4R9f 

pp 

8* 

APP 

30 

7^ 

PR 

PR 

P8 

1 ?^RPP(^94 

pp 

8* 

MAY 

31 

75 

PR 

PP 

pp 

1 ?SRR4^9*^ 

pp 

8* 

JI'N 

30 

75 

30 

30 

30 

1P^PRS?97 

pp 

8* 

JI'L 

31 

75 

30 

*80 

1 00 

*PP 

1 PRRPR4P1 

pp 

8* 

Al'P 

31 

75 

30 

*80 

1 PS 

*P? 

1 p5p55f,p7 

♦ **ciipTOTAI.*»* 


*0 

1 ?74 

739 

1 30? 

pr 

87 

J"l. 

31 

74 

?7 

P7 

1 A4747 

PP 

87 

A"P 

3 1 

7 4 

97 

?7 

!?«^p^;4t9p 

pp 

87 

SFP 

30 

7 4 

97 

?7 

1 pt;p  A(^^97 

PP 

P7 

OCT 

31 

74 

97 

?7 

PP 

R7 

NOV 

30 

74 

9n 

?7 

jpSR^Of 41 

PP 

87 

OFC 

3 I 

•7  4 

97 

?7 

1 4 7 

PP 

87 

JAN 

31 

75 

97 

P7 

1 PSPf 1 P44 

PP 

87 

pro 

?8 

75 

97 

P7 

l?«;pfl714 

PP 

87 

MAP 

31 

75 

97 

P7 

1 P^P(t4P97 

PP 

87 

APR 

30 

75 

97 

97 

?7 

1 ?RRAS(^9<; 

PP 

87 

MAY 

T 1 

75 

97 

97 

?7 

1 ?<;P(C4(ft9A 

PP 

87 

JI'N 

30 

75 

99 

P9 

?9 

1 pRp A^?9R 

pp 

87 

J"L 

3| 

75 

?9 

47  S 

1 59 

/,R* 

1 P^f^A5/>5p 

pp 

87 

A"P 

31 

7 5 

?9 

4P«^ 

1 75 

*8S 

1 P<;qa^AC^P 

1 


1 i 


■-i 
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FUNniNn  PPOFILF  PFPOFT 


AFF  ASOFJMLY  FY75  SHIPS  nOMPLFTI\'P  PPlOP  TO  .aTH  Ol'AFTFF 

RFPORT  003  004001  PFC  IF  197F 

HULL  AS  OF  PFIOF  CNTYR  CNTYF  FST  CNTYF 

DATF  YFFNP)  PLAN  FNP  RTMT 

(1000)  (1000)  (1000)  FCniP 

♦ **FiipTOTAL*** 

S8  1P9A  409  1?9A 


367 


r 


l-'Ol'LD  YOU  LIKF  TO  SUBMIT  ANOTHFP  OUFPY?-  YF? 


PLFAFF  INPUT  PUFRY  COMMANDS 
PUFRY  PIPS 

IF  FNDACTVTY  IS  TABDC-T  AND  HULL  IS  LPD  lA  OP  LSD  ?P  OP  LST  11B1 
OP  PC  Hf.  OR  PC  B7? 

PFPORT  SOP 
SOPT  ON  HULL 

HFAD  1 S7A  PDPT  INFORMATIONS 

IF  FNDACTV/TY  IS  TSPOPT  AND  HULL  IS  PLPD  lA  OP  LSD  ?9  OP  LST  llPl 
OP  PC  86  OR  PC  87? 

PFPORT  SD6 
SORT  ON  HULL 

HFAD  I STS  BDC-T  INFORMATIONS 

IF  FNDACTVTY  IS  76PD0T  AND  HULL  IS  LPD  lA  OR  LSD  ?R  OP  LST  1181 
OP  PC  86  OR  PC  87? 

RFPOPT  S06 
SOPT  ON  HULL 

HFAD  1 576  PDCT  INFORMATIONS 
SFND 

YOUR  OUFPY  HAS  PFFN  ACCFPTFD 


FOR  FACH  GUFSTION,  TYPF  IN  D,  T,  OF  P. 


PUFRY 

OPS, 

OHFSTION 

NO. 

I , 

P 

HITS-T 

OUFPY 

0PS, 

PUFSTION 

NO. 

?. 

HA? 

HITS 

OUFRY 

OPS. 

CUFSTION 

MO. 

0, 

HA? 

HITS-T 

368 


APPORTIONMFNT 
lA  PRAT  TNFOPMATIR\’ 


REPORT  SPIfe  0PI5PIOI 


hull 


PG  86 
PG  87 


MAN 

HOUR? 


LAPOR 

FUNP 

^8S 

A60 


MATL 

Fl'NP 


1 

1 1 G 


I 'N  1 T 
rOFT 

60S 

S7G 


PFC  IS  I97S 


PCniR 

l?S8S?fSf 
I ?S86?6S7 


i 


APPORTIONMFNT 
76  PDPT  INFORMATION 


REPORT  S06  005003  PRC  )r  1975 


HULL 

MAN 

LABOR 

MAIL 

UNIT 

HOURS 

FUNP 

Fl'Nn 

COST 

Rcnio 

LPD 

63AiS 

1 

778  a 

07P0056AA 

LSD  P9 

506A 

1?A9 

631  3 

031P956A5 

LST  118  1 

A00? 

1 IPtF 

5110 

P00P056A7 

PP  86 

AA3 

510 

I05B5S6S? 

PP  87 

A A5 

f>l 

51? 

1 P5P65653 

V'Ol'LD  YOU  LIKE  TO  SUPMIT  ANOTHFP  OlTPY?-  NO 


"1 


????  PEPnEF 


PLFASF  INPUT  PFPORT  DFFINITIONF. 

ID  PASF2 
REPORT  C»PI5 
DPTYPF  I?  PCDID 

l»'HEAD  f APPORTIONMENT  INFORMATION? 

COL  HEAD  1 = FFND/ACTVTY? 

COL  HEAD  ? = IHULLf 

COL  HEAD  3 = fMAN/DAYSf 

COL  HEAD  A = ?LABOR/EUND/(  I PIPI0)  ? 

COL  HEAD  S = rMATL/ENDINO/C 1000)5 
COL  HEAD  A = TUN  I T/C03T/ ( I 000 ) 5 

PRINT  ENDACTVTY#  HULL*  PDPTLDAYR*  PDATLMNY. PPOTMMNY.  PnOTUCOET 
5 END 

PEPOPT  DEFINITION  FPROP  SUMMARY 


ID  - PASF? 

REPORT  - 005 

NO  ERRORS  FOUND  - PFPORT  DEFINITION  ACCEPTED 
????  lOUFPY 

YOU  HAVE  SELECTED  THE  INTERACTIVE  PUEPY  OPTION. 
V'OULD  YOU  LIKE  AN  EXPLANATION  OE  THE  SYSTEM7-N0 


SELECT  ONE  OE  THE  FOLLOUINC  DATA  PASFS 
IP  LOGISTICS  DOCUMENT  DATA  PANK 

31  YURSO  DATA  PANK 

32  MKPS-PASE-2 
??  32 

PLEASE  INPUT  DUEPY  COMMANDS 
OUEPY  OOP 

IE  SUFFIX  ENDACTVTY  IS  PDCT  AND  HULL  IS  LPD  I A DP  LSD  29  OP  LST  11P1 
OP  PC.  PA  OP  PC  P7? 

PEPOPT  005 

SORT  ON  ENDACTVTY  AND  HULL 

HEAD  1 5LPD  lA  - LSD  29  - LST  llPl  - PG  PA  - PC-  P7  HI'LLST 
HEAD  2 5DFMDNSTPATI0N  OE  THE  INTEGRATED  DUEPY? 

SEND 

YOUR  DUEPY  HAS  PFFN  ACCEPTED 


FOP  EACH  CUESTIOM,  type 
DUEPY  OOA.  DIiertION  NO. 


IN  D.  T.  op  p. 
1 , HAS 


7 HITS-T 


i 

I 

I 


APPOFTION'MFNT  INFOPMPTION 


FIVF  FHIP  PCFNAFin 

DFt-’ON^TPATION  OF  THF  IN'TFPRATFn  omfFY 


PFP0P1  ?P5  PPAPPl  PFC  !S  197F 


FNP 

Pi'l.i. 

MAN 

LAPOP 

MAIL 

UNIT 

ACH'TY 

DAYS 

FPN'P 

FNDINO 

COST 

( 1 PPP) 

( 1888) 

PCD  in 

74BDPT 

pr-  86 

/.R  S 

1 ?8 

68S 

1?S8S?6S6 

74PnOT 

PO  87 

1 1 8 

S78 

1 ?S86?6S7 

7fPDGT 

LPB  I 4 

1 448 

7784 

87P88S644 

76BDPT 

LSD  ?9 

1 ?49 

68  18 

881 P9S645 

76BDPT 

LST  1181 

1 1 88 

8118 

P88P8S647 

76PnBT 

pr  86 

6 7 

SI  8 

1 PS8SS6S? 

7 ABBOT 

PP  87 

67 

SI? 

1P88686S8 

1 


.1  VOULD  YOU  LIKF  TO  SI.'PM!T  ANOTHFP  OUFFY7- 

PATA  PASF  - PAFF?  YFF 

PLFASF  INPI'T  CI'FPY  COMMANPF 
PI'FPY  PP7 

IF  HULL  IF  LPP  lA  OP  LFP  P9  OR  LFT  llPl  op  PP  PA  OR  PP  P7? 
RFPORT  PFP 

SORT  ON  HI'LL  ANP  ASOFPATF 

HFAD  I fINFORMATION  APOUT  INFORMATION  IN  THF  PASFf 
, HFAD  ? SFIVF  SHIP  RFCOPP  POPULATION  ANANYSIST 

I HFAP  3 fNA'/LIS  IS  OPFPATIONALF 

' SFND 

> YOUR  PUEPY  HAS  PFFN  AOCFPTFP 


FOP  FACH  PUFSTION,  TYPF  IN  P,  T.  OR  P. 

PUF.RY  007.  PUFSTION  NO.  1,  HAS  90  HITS-T 


r 

! 


U 


t 

i 


1 


I- 
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SHIP  nVFPHPI'L  PPnPILF 
INFORMATION  APOI’T  INFOPMATION  IN  THF  PASF 
FIVF  SHIP  RFCORP  POPULATION  ANANYSIS 


NAVLIR  IS  OPFPATIONAL 


REPORT 

PSB 

007001 

DFC  15  1975 

ASOF 

START 

FND 

TYPF 

FND 

SCHFD 

DATE 

PATE 

DATF 

01/HL 

ACTVTY 

ACTVTY 

PCDID 

NOV 

09 

71 

NOV 

09  71 

DFC 

?0 

71 

PS 

072003287 

JUL 

31 

7A 

AUP 

75 

APR 

76 

75AFR 

072004345 

AUP 

31 

7A 

AUP 

75 

APR 

76 

75AFP 

072004197 

SEP 

30 

74 

AUP 

75 

APR 

76 

75AFP 

07200030? 

OCT 

31 

74 

AUp 

75 

APR 

76 

75AFP 

072000471 

NOV 

30 

74 

AUP 

75 

APP 

76 

75AFR 

072000647 

DFC 

31 

74 

AUP 

75 

APR 

76 

75AFP 

072000848 

JAN 

31 

75 

AUP 

75 

APP 

76 

75AFP 

072001049 

FEP 

2B 

75 

AUP 

75 

APR 

76 

75AFR 

■072001316 

MAR 

31 

75 

AUP 

75 

APR 

76 

75AFP 

072004899 

APR 

30 

75 

AUP 

7 5 

APR 

76 

75AFP 

072005097 

MAY 

31 

75 

AUP 

75 

APR 

76 

75AFP 

07.2004698 

JUN 

01 

75 

DEC 

71 

76PDPT 

072005644 

JUN 

30 

75 

AUP 

75 

APR 

76 

75AFR 

072005303 

JUL 

31 

75 

AUP 

75 

APP 

76 

76CFY 

072005437 

AUP 

31 

75 

AUP 

75 

APP 

76 

76CFY 

07200559? 

APR 

15 

77 

AUP 

79 

PPOJ 

072000153 

APR 

?8 

A4 

APR 

?8  6 4 

JUL 

30 

64 

PO 

031293301 

FFB 

?6 

68 

FFB 

26  68 

JUL 

?2 

68 

PO 

03129330? 

JUL 

01 

71 

JUL 

01  7 1 

NOV 

01 

71 

RO 

031293303 

JUL 

31 

74 

AUP 

75 

JAN 

76 

75AFP 

031294347 

AUP 

31 

74 

AUP 

75 

JAN 

76 

75AFR 

031294199 

SEP 

30 

74 

AUP 

75 

JAN 

76 

75AFP 

031290304 

OCT 

31 

74 

AUP 

75 

JAN 

76 

75AFP 

031290474 

NOV 

30 

74 

AUP 

75 

JAN 

76 

75AFP 

031290649 

DEC 

31 

74 

A"P 

75 

JAN 

76 

75AFP 

031 290850 

JAN 

31 

75 

AUP 

7 5 

JAN 

76 

75AFP 

031291051 

FEB 

?8 

75 

AUP 

75 

JAN 

76 

75AFP 

031291318 

MAR 

31 

75 

Aup 

75 

JAN 

76 

75AFP 

031294901 

APR 

30 

75 

AUP 

75 

JAN 

76 

75AFR 

031295098 

MAY 

31 

75 

AUP 

75 

JAN 

76 

75AFP 

031294700 

JUN 

01 

75 

JUL 

71 

NOV 

71 

76PDPT 

031295645 

JUN 

30 

75 

AUP 

75 

JAN 

76 

75AFP 

031295305 

JUL 

31 

75 

AUP 

75 

JAN 

76 

76CFY 

031295437 

AUP 

31 

75 

AUP 

75 

JAN 

76 

76CFY 

031 295593 

APR 

15 

77 

FFB 

80 

PROJ 

0312901 77 

DATA  BASF 

- BASF? 

OCT 

03 

66 

OCT 

03  66 

AUP 

?0 

70 

NC 

200203318 

JUL 

1 3 

70 

JUL 

1 3 70 

AUP 

20 

70 

FO 

200203319 

JUL 

31 

74 

AUP 

75 

FFB 

76 

75AFP 

200204349 

AUP 

31 

74 

AUP 

75 

FFB 

76 

75AFF 

200P04P01 

SFP 

30 

74 

AUP 

75 

FFP 

76 

75AFR 

200200306 

OCT 

31 

74 

AUP 

75 

FFB 

76 

75AFP 

200200476 

NOV 

30 

74 

AUP 

75 

FFP 

76 

75AFP 

200200651 

PEC 

31 

74 

AUP 

75 

FFP 

76 

75AFP 

200P0085? 

JAN 

31 

75 

AUP 

75 

FFP 

76 

75AFR 

200201053 

FFB 

?B 

75 

AUP 

75 

FFR 

76 

75AFP 

200201 320 

RHIP  rn/ppHAHL  PPOFILF 


INFOPMATION  PPOUT  INFnpMPTIOM  IN  THF  PPFF 
FIV'F  SHIP  PFCOFF  POPULATION  ANANYPIF 
NAVLI?  1?  OPFFPT TONAL 


PF.POPT  PSP  PI070P1  OFT  IS  197^ 


ASOF 

START 

FNP 

TYFF 

FND 

SCHFP 

OATF 

PATF 

PATF 

OVHL 

ACTUTY 

ACT”TY 

pro  in 

MAP 

31 

75 

Aup 

75 

FFP 

7A 

75AFP 

P00P04903 

APR 

30 

75 

AUP 

7.5 

FFP 

75AFP 

P00P05  1 

MAY 

31 

75 

AUP 

75 

FFP 

7A 

75AFP 

P00P0470? 

JUN 

01 

75 

MAP 

71 

76PnCT 

P00P05647 

JUN 

30 

75 

Aup 

75 

FFP 

75AFP 

P00P057O7 

JUL 

31 

75 

AUP 

75 

MAP 

7^ 

76CFY 

P00P0543P 

A UP 

31 

75 

AUp 

75 

MAP 

If- 

76CFY 

P00P05594 

APR 

1 S 

77 

OCT 

79 

PPOJ 

P00P001 70 

MAY 

01 

73 

JUN 

71 

JAN 

17 

7APPPT 

1 ?6p6?|t56 

MAR 

01 

7ii 

MAP 

01  7/i 

JUN 

1 1 7^ 

PO 

1 ?5P64PIJ  4 

JUL 

31 

7A 

JAN 

76 

APP 

If- 

75AFP 

I P5P6404P 

AUP 

31 

JAN 

76 

APP 

lf> 

75AFP 

1 ?5R6^1 9 I 

SFP 

30 

7-s 

JAN 

76 

APP 

If- 

75AFF 

1 P5P50P96 

OCT 

31 

7il 

JAN 

76 

APP 

7f 

75AFP 

1 ?5B5(«465 

NOV 

30 

7A 

JAN 

76 

APP 

If- 

75AFP 

1?6B5044(» 

PFC 

31 

7/J 

JAN 

76 

APP 

If- 

75AFR 

I P6R5AP4? 

JAN 

31 

75 

JAN 

76 

APP 

If 

7 6 AFP 

1 ?5P51 040 

FFP 

?P 

75 

JAN 

76 

APP 

If- 

75AFP 

1 PSR61 01 0 

MAP 

31 

75 

JAN 

76 

APP 

If- 

75AFP 

1 P5PR4P96 

APP 

30 

75 

JAN 

76 

APP 

If. 

75AFP 

1 

MAY 

31 

75 

JAN 

76 

APP 

If- 

76^FP 

1 P5P54695 

JUN 

01 

75 

MAP 

7A 

MAY 

Ifi 

76Pnr-T 

1 pRpPSppp 

JUN 

30 

75 

JAN 

76 

APP 

If- 

76AFP 

1 P5P56P97 

JUL 

31 

75 

JAN 

76 

APP 

If- 

76CFY 

I P606S451 

AUP 

31 

75 

JAN 

76 

APP 

If- 

76CFY 

1 P5P56607 

APR 

1 s 

77 

AUP 

75 

PPOJ 

IP5P5PP99 

MAY 

01 

73 

JI'N 

71 

JAN 

17 

7^PnCT 

1 P5P6P657 

MAP 

01 

7A 

MAP 

0 1 7 A 

JUN 

1 1 7/i 

PO 

1 P5P640I 5 

Jl'L 

31 

7^ 

JAN 

76 

APP 

7A 

75AFF 

1 P5P64340 

AUP 

31 

7^ 

JAN 

76 

APP 

7A 

T'^AFP 

1P'^P64!9? 

SFP 

30 

7^ 

JAN 

76 

APP 

7fi 

75AFP 

1 P5S60P97 

OCT 

31 

7^ 

JAN 

76 

AFP 

If- 

756PP 

1 P5P4P466 

NOV 

30 

lA 

JAN 

76 

APP 

If- 

76AFP 

1 P6PPP441 

PFC 

31 

7^ 

JAN 

76 

APP 

If- 

75AFP 

I P5P60P4O 

JAN 

31 

75 

JAN 

76 

APP 

If- 

75AFP 

1 p5P6 1 044 

FFP 

?P 

75 

JAN 

76 

APP 

If- 

75AFP 

1P5P61 01 4 

MAP 

31 

75 

JAN 

76 

APP 

If- 

75AFP 

1 P6P64P97 

APP 

30 

75 

JAN 

76 

APP 

If- 

75AFP 

1 PPP4SP9P 

MAY 

31 

75 

JAN 

76 

APP 

7^ 

7 5 AFP 

1 P5P64696 

JUN 

01 

7 = 

MAP 

7 A 

MAY 

Ifi 

76P0PT 

1 PPP444P0 

JUN 

30 

75 

JAN 

76 

APP 

If- 

75AFP 

1 pRP4Pp9p 

JUL 

31 

75 

JAN 

76 

APP 

If- 

76CFY 

1 P6PP64SP 

AUP 

31 

75 

JAN 

76 

APP 

If 

76CFY 

1 P6P4640P 

APP 

1 s 

77 

Aur 

7R 

PPOJ 

) pppAHI pp 
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WOULP  YOL'  LIKF  TO  Ft'PMIT  ANOTHFF  FliFFY?-  YFF 

PLFASF  INPl'T  PUFRY  COMMANDS 
nUFRY  POB 

IF  RCDID  IS  07?PflO?B7  OP  0OIP97.70I  OR  PPPPPOOIB  OP  IPSRSPASA 
OR  1PSBAP6S7? 

PRINT  RCDID.  HULL.  SHIP,  DIC 
SORT  ON  RCDID 

HFAD  I f DFMONSTRATION  OF  THF  MULTIPHASF  SPLIT  KFY  PFTPIFVAL  POUTPf 

HFAD  ? SFND  OF  THF  F I VF  SHIP  SCFNARlOf 

fFND 

YOUR  PUFRY  HAS  PFFN  ACCFPTFD 


FOP  F.ACH  CUFSTION.  TYPF  IN  D,  T.  OP  P. 

OUFPY  00B.  PUFSTION  NO.  1,  HAS  HITS- 

ILLFCAL  CHAPACTFR,  TRY  AOAIN  T 


376 


PFMONSTPATION  OF  THF  MI'LTIPHAFF  5PLIT  KFY  PFTFIFUAL  POFFP 


RFPORT  PFT  eiPRPiPII  PFP  IR  197S 


iPCPJP:  R31P933PI1 

HULL!  LSP  29 
SHIP!  PLYMOUTH  POCK 
I'lC!  3129 


i RCDIP!  272023297 

I HULL!  LPP  lA 

C SHIP!  TRFNTON 

p II I C!  7222 

; 

; RCPIP!  I25R52A5A 

; HULL!  PP  R6 

SHIP:  ANTFLOPF 

‘ ■ UIC!  125RS 


RCPIP!  12SRA2A57 
HULL!  PC  R7 
SHIP:  PPAPY 
UIC!  12 SR 6 

i 

PCPIP:  22222331R 
HULL!  LST  11«1 
SHIP:  SUMTFP 

"1C!  22222 


j 

i 

i 

i 


i 
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CINCLANTFLT 

Scenario  of  August  1975 
Funding  Report 

Terminal  Session  and  Report  Samples 


Attachment  #4 
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NSPnC  INTFFCOM  \JA.p 

ffffF  l3n(S/3S. 

FLFPSF  LOFIM 

LOPIN»  PHWFU'FA''FP,  | 1 PCf  00P?n,  Fl'P 
COMMAND-  FTL»500 
command-  COMPADF, SHAFP 


COMRADF  TIMFs 

DATF:  1P/IA/7S 

SHARP  SHBSYSTFM  FNTFPFD 
????  PFPDFF 

PLFASF  INPUT  PFPOPT  DFFINITIONF. 

ID  PASF? 

PFPOPT  FNP 

MHFAD  rSHIP  FMNDINF  ACTV/ITYf 

COL  HFAD  1 = SHl'LLf 

COL  HFAD  P = fFND/ACT''TYT 

COL  HFAD  0 = yPYRYP/FND/(  1 000)!r 

COL  HFAD  A = «CNTYP/PLAN/( 1 000)« 

COL  HFAD  5 = JCNTPLN/ALLYPS / ( 1 000 ) ? 

COL  HFAD  A = fTOTFND/ALLYRS/TODTFf 
COL  HFAD  7 = FCNTYP/FND/TODTFT 
COL  HFAD  P = TFST/CNTYR/PPMTF 
COL  HFAD  9 = fPST/THOP/OViHLS 

PRINT  Hl'LL*  PYPYPFND*  CNTYPPLN,  CNTPLNTOT*  TOTFND.  CNTYPFND. 

FSTCNTYPOT.  FSTOVHL 

5FND 

PFPOPT  DFFINITION  FRROP  S\<MMAPY 
ID  - BASF? 


PFPOPT  - FND 

NO  FRPOPS  FODND  - RFPOPT  DFFINITION  ACCFPTFD 
????  PFPDFF 


PLFASF  INPUT  PFPOPT  DFFIVITIONS. 

ID  BASF? 

PFPOPT  FLT 

MHFAD  fSHIP  SCHFDULF  PFPOPTJ 
COL  HFAD  I = yFND/DATFF 
COL  HFAD  P = fSTAPT/DATFS 
COL  HFAD  0 = FHI'LLf 
COL  HFAD  A = TSHIPSf 
COL  HFAD  5 = »YAPD*. 

COL  HFAD  A = «7/OMHL? 

PPINT  FNDATF*  STAPTDATF*  HI'LL»  SHIP#  FCLTY#  PFP^NTO^'HL 
♦ FND 


PFPOPT  DFFINITION  FPPnp  Sl'MMAPY 


ID  - BASF? 

REPORT  - FLT 

NO  ERRORS  FOtlND  - PFPOPT  DFFINITION  ACOFPTFD 
????  IPUFRY 

YOU  HAVF  SFLECTFD  THF  INTFPACTIVF  OUFPY  OPTION. 
WOULD  YOU  LIKF  AN  FXPLANATION  OF  THF  SYSTFN?-N0 


SFLFCT  ONF  OF  THF  FOLLOWING  DATA  PASFS 
18  LOFISTICS  DOCUMFNT  DATA  PANK 
31  YURSn  DATA  BANK 
3?  HKPS-BASF-? 

??  3? 

PLFASF  INPUT  rUERY  COHMANDS 
PUEPY  SDP'S 
OUFPY  S03 

IF  ASOFDATF  IS  750831? 

REPORT  sen 

SORT  ON  (*5,4)80010 

HFAD  1 SAUFUST  1975  INFORMATIONS 

HFAD  ? TATLANTir.  FLFFT  ACTIV/ITY? 

HEAD  3 SFUNDINF  SCFNAPIOf 
SEND 

YOUR  OUERY  HAS  PFFN  ACCEPTED 


FOR  EACH  CUFSTION,  TYPE  IN  D,  T,  OP  B, 

OUFPY  S03,  OUESTION  NO.  I,  HAS  lAA  HITS-T 


5HIP  e’l'NPINP  .‘SCHFPMLF 


AIT-UST  1975  INFOPMATimo 
ATLANTIC  FLFFT  ACTIWITY 

1 

j FliNPINP  FCFNAPin 

i REPORT  FCD  SOSCdl  PFC  I A 197«; 


HLILL 

SHIP 

YARD 

START 

FNP 

FNP 

DATF 

PATE 

ACTVTY 

SSN  678 

APCHFPFI5H 

JUN 

76 

JUN 

77 

76CFY 

SSN  585 

SKIPJACK 

SP 

JliL 

74 

JUL 

76 

76COR 

5SN  591 

SHARK 

SP 

AUP 

74 

FFP 

76 

76COP 

SSN  604 

HADDO 

SP 

AUP 

73 

JI'L 

75 

76C0P 

SSN  664 

SFA  DEVIL 

PT 

JUL 

74 

JUN 

75 

76C0R 

SSN  670 

F INPACK 

N 

JUL 

74 

MAY 

75 

76COR 

SSN  674 

TFFPANP 

PT 

OCT 

74 

OCT 

75 

76COR 

SSN  676 

PILLFISH 

PT 

JAN 

75 

JAN 

76 

76C0R 

CV  66 

AMERICA 

N 

PFC 

74 

OCT 

75 

76C0P 

AFS  2 

SYLVAN I A 

S 

MAY 

75 

NOV 

75 

76COP 

AO  99 

CANISTEO 

3 

MAP 

75 

SEP 

75 

76COP 

APS  6 

ESCAPE 

SJ 

JUN 

75 

NO\» 

75 

76COP 

CP  34 

PIDDLE 

PA 

APR 

75 

APR 

76 

76C0P 

DP  941 

pM  PONT 

N 

APR 

75 

PFC 

75 

76COP 

DDC  3 

KINP 

N 

MAY 

75 

MAR 

76 

76COP 

FF  1059 

SIMS 

PH 

JUN 

7*; 

MAR 

77 

76COP 

FFP  6 

Fl'REP 

C 

JAN 

75 

OCT 

75 

76COR 

LPD  1 

PALE  I PH 

6 

AUP 

74 

SFP 

75 

76COR 

LSD  30 

FORT  SNFLLINP 

S 

FFP 

75 

OCT 

75 

76COR 

LSD  37 

PORTLAND 

6 

JUN 

75 

PFC 

75 

76COP 

PP  93 

VFL  CH 

5 

JUN 

75 

OCT 

75 

76COP 

AP  520 

ALACRITY 

4 

JUN 

75 

OCT 

75 

76COP 

AC  521 

ASSl'PANCE 

6 

JUN 

75 

OCT 

75 

76C0P 

FF  1038 

MCCLOY 

PH 

MAP 

75 

SFP 

75 

76C0P 

AP  38 

Pl'PFT  SOUND 

N 

M4Y 

75 

SFP 

75 

75COP 

DDP  45 

PFFFY 

r 

APF 

75 

MAY 

76 

76COP 

FFP  5 

PAPF 

PH 

APR 

75 

JAN 

76 

76COP 

DDP  2 

ADAMS 

PH 

FFP 

75 

PFC 

75 

76COP 

AOF  2 

milvaukff 

PH 

FFP 

75 

SFP 

75 

76COP 

LST  1180 

MANITOVOC 

e 

JAN 

75 

AUP 

75 

76COR 

PD  937 

DAVIS 

r 

JAN 

75 

PFC 

75 

76COP 

DD  938 

INPPAM 

c 

OCT 

75 

SFP 

75 

76C0P 

DPP  17 

CONYNPHAM 

N 

OCT 

75 

A|IP 

75 

76COR 

FF  1072 

PLAKFLY 

r 

JUL 

75 

MAP 

76 

76CFY 

LPH  9 

PUAM 

PH 

Jl^ 

75 

FFP 

76 

76CFY 

SSN  675 

FLUFF  I SH 

N 

J"L 

75 

JUL 

76 

76CFY 

DDP  23 

PYPP 

N 

AUP 

75 

JI'N 

76 

76CFY 

PATA  PASF  - RASF2 

LPP  14 

TFFNTON 

5 

AUP 

75 

APR 

76 

76CFY 

LSD  29 

PLYMOUTH  POCK 

6 

AUP 

75 

JAN 

76 

76CFY 

LST  1181 

SUMTFP 

5 

AUP 

75 

MAP 

76 

76CFY 

SSN  653 

FAY 

c 

Allp 

75 

FFP 

77 

76CFY 

SSN  606 

TINOSA 

SP 

AUP 

75 

FFP 

77 

76CFY 

SSN  605 

JACK 

PT 

OCT 

75 

FTP 

77 

76CFY 

DDP  19 

TATTNALL 

c 

OCT 

75 

AUP 

76 

76CFY 

FF  1075 

TFIPPE 

c 

OCT 

7*; 

AUP 

76 

76CFY 

DD  943 

PLANPY 

3 

OCT 

75 

SFP 

76 

76CFY 
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FliNPiNr  srFwPFin 


RFPORT  SCD  SP3P01  PFC  IF  197S 


I 


j 


HULL 

SHIP 

YAFP 

START 

PATF 

FNP 

PATF 

FNP 

ACTVTY 

ATF  1ft? 

SHAKORI 

S 

NOV  7S 

MAP 

7ft 

7ftCFY 

ppn  10 

SAMPSON 

PH 

NOV  7S 

OCT 

7ft 

7ftCFY 

FF  10ft8 

VPFFLAND 

PH 

RFC  7S 

NOV 

7ft 

7ftCFY 

DDP  A 

LAV'PFNCF 

N 

PFC  7S 

NOV 

7ft 

7ftCFY 

] 

AF  ?8 

SANTA  PARPAPA 

SJ 

PFC  75 

SFP 

7ft 

7ftCFY 

AD  19 

YOSFMITF 

SJ 

JAN  7ft 

JUN 

7ft 

7ftCFY 

■i 

PP  Rft 

ANTFLOPF 

NFLM 

JAN  7ft 

APF 

7ft 

7ftCFY 

PP  87 

FFADY 

NFLM 

JAN  7ft 

APP 

7ft 

7ftCPY 

SRN  ft50 

PAPPO 

SP 

JAN  7ft 

APP 

77 

7ftCFY 

AS  3A 

CANOPUS 

c 

JAN  7ft 

SFP 

7ft 

7ftCFY 

SSN  ftft0 

SAND  LANCF 

c 

JAN  7ft 

JAN 

77 

7ftCFY 

■■ 

AP  S 

VULCAN 

s 

JAN  7ft 

Aun 

7ft 

7ftCFY 

PP  9A0 

MANLFY 

PH 

JAN  7ft 

PFC 

7ft 

7ftCFY 

PR  933 

PAPPY 

PH 

JAN  7ft 

PFC 

7ft 

7ftCFY 

SSPN  ft?9 

BOONF 

PT 

JAN  7ft 

MAY 

77 

7ftCPY 

LSD  38 

PFNSACOLA 

S 

PFP  7ft 

AI'P 

7ft 

7ftCFY 

LST  1188 

SAPINAV 

•; 

FFP  7ft 

AUP 

7ft 

7ftCFY 

APF  3 

LA  SALLF 

SUPIC 

MAP  7ft 

JUN 

7ft 

7ftCFY 

SSN  ftftl 

LAPON 

NN 

MAF  7ft 

JUN 

7ft 

7ftCPY 

LPR  1? 

SHPFVFPORT 

s 

MAP  7ft 

OCT 

7ft 

7ftCPY 

DP  931 

SHFRMAN 

T 

MAP  7ft 

JAN 

77 

7ftCFY 

'"I 

AS  3ft 

SPFAP 

N 

APP  7ft 

OCT 

7ft 

7ftCFY 

:-l 

■1 

APF  A 

PFTPOIT 

s 

APF  7ft 

FFP 

77 

7ftCFY 

FF  1078 

HFVFS 

r 

APP  7ft 

FFP 

77 

7ftCFY 

FF  1079 

BOVFN 

MAY  7ft 

MAR 

77 

7ftCFY 

LPH  1? 

INCHON 

MAY  7ft 

NO\' 

7ft 

7ftCFY 

DPP  38 

LUCF 

JUN  7ft 

JUL 

77 

7ftCFY 

MSO  AAg 

ILI.USI  VF 

JUN  7ft 

SFP 

7ft 

7ftCFY 

cw  Ap 

POOSF''FLT 

pFP  75 

PPC 

75 

7ftPPA 

WOULD  YOU  LIKF  TO  SUBMIT  ANOTHPR  OUFRY? 
NO 


????  RFPDFF 


KFRP  IS  = I' 

IFPR  IS 
BIN-?FRO= 

DELAY  IN  OBTAINING  REPORT  DEFINITION  FILE 
ARE  YOU  V'lLLINP  TO  VAIT  A EEt'  SErONDS?-YES 

KERR  IS  = U 

I ERR  IS 

BIN-?EPO= 

DELAY  IN  OBTAINING  REPORT  DEFINITION  FILE 
ARE  YOU  UILLINP  TO  WAIT  A EFl-'  SECONDS7-YFS 


PLEASE  INPUT  REPORT  DEFINITIONS. 


ID  BASE? 

REPORT  END 

MHFAD  fSHIP  EUNDIND  ACTIVITY* 


COL  HEAD  1 
COL  HEAD  ? 
COL  HEAD 
COL  HEAD 
COL  HEAD 
COL  HEAD 
COL  HEAD 
COL  HEAD 
COL  HEAD 


SHULLS 

SEND/ACTVTV* 

SPYRYR/END/( 10O0)S 
5CNTYR/PLAN/< 1 0D?)S 
SCNTPLN/ALLYPS/< 1P0P)S 
STOTEND/ALLYRS/TODTE* 
SCNTYP/FND/TODTES 
SEST/CNTYP/RDMTS 
SEST/THOF/OVHLS 
PRINT  Hia.L»  FNDACT''TY.  PYRYPENfl,  CNTYRPLN, 
CNTYRFND.  ESTCNTYPGT.  FSTOUHL 
SEND 


CNTPLNTOT#  TOTFND, 


REPORT  DEFINITION  ERROR  SUMMARY 
ID  - BASF? 


REPORT  - END 

NO  ERRORS  FOUND  - REROPT  DEFINITION  ACCEPTED 
????  IDIIEPY 
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I 


YOU  HAVF  SFLFCTFn  THF  INTFFACTI'/F  PUFFY  OPTION. 
WOULD  YOU  LIKF  AN  FXPLANATION  OF  THF  FYFTFH7-NO 


SFLFCT  ONF  OF  THF  FOLLOWINF  DATA  PAFFF 
18  LOFIFTICS  DOCUMFNT  DATA  PANK 

31  YUPSO  DATA  BANK 

32  MKFS-PA5F-P 
??  32 


PLFAFF  INPUT  PUFFY  POMMANDF 
PUFRY  SP3 

IF  ASOFPATF  IS  75P831? 

PFPORT  FNP 

SORT  ON  FNDACTV/TY  ANP  HULL 

PRINT  SUBTOTAL  PYRYRFNP,  CNTYRPLN. . PNTPLNTOT.  TOTFNP,  CNTYRFND. 
FSTCNTYRPT.  FSTOVHL  ON  FNDACTUTY 

PRINT  TOTAL  PYRYRFNP,  PNTYRPLN*  CNTPLNTOT#  TOTFNP.  CNTYRFND. 
ESTCNTYRPT.  FSTOVHL 

HEAD  1 fPFPIOD  FNPINF  AliPUST  17975? 

HEAD  2 SATLANTIC  FLEET? 

HEAD  3 ?FUNDINF  SCENARIO? 

?FND 

YOUR  PUFRY  HAS  PFFN  ACCFPTFD 


FOP  EACH  PUFSTION.  TYPE  IN  P.  T.  OR  P. 

PUFRY  SP3.  PUFSTION  NO.  I.  HAS  )AA  HITS-T 


DATA  PASF  - PASF2 


1 


i 


A 


( 


\ 


A 


: 


i 

> 

r* 

% 

k 


SHIP  funpinp  actiwity 
PERinp  FNniNP  Al'PnST  197S 
ATLANTIC  FLFFT 


FI'NniNC  SCFNAPIO 


REPORT 

FND  SDSCrPl 

DFC 

lA  1975 

HLILL 

END 

PYRYR 

CNTYP 

CNTPLN 

TOTFND 

CNTYR 

FRT 

FST 

ACTVTY 

FND 

PLAN 

ALLYRS 

ALLYRS 

FND 

CNTYR 

THOR 

OBPipiJ 

( 1 Pippi) 

(1P)O0> 

TODTF 

TODTF 

RPMT 

OV/HL 

AD  38 

75C0R 

831 

831 

831 

831 

♦ ♦♦Sl'PTOTAL*** 

831 

0 831  831 

0 

0 

831 

AE  23 

76AFR 

700 

310 

310 

700 

AOR  ^ 

76AFR 

87 

500 

382 

295 

500 

ARS  A1 

76AFR 

150 

91 

91 

1 50 

AS  1 1 

76AFR 

500 

500 

AS  33 

76AFR 

500 

500 

ATF  159 

76AFF 

120 

91 

91 

120 

ATF  IA0 

76AFP 

60 

60 

ATF  lAl 

76AFR 

1029 

60' 

1029 

60 

ATS  1 

76AFR 

100 

437 

337 

237 

437 

CP  19 

76AFF 

500 

291 

291 

500 

CP  20 

76AFR 

200 

200 

CP  2fi 

76AFP 

600 

600 

CP  A 

76AFR 

210 

700 

286 

76 

700 

CV  59 

76AFR 

100 

3000 

3100 

3000 

3000 

DD  9AA 

76AFR 

200 

200 

DDP  35 

76AFR 

300 

300 

DPP  40 

76AFR 

200 

200 

FF  1040 

76AFR 

I 00 

100 

FF  1043 

76AFR 

1 50 

150 

FF  1044 

76AFR 

1 

500 

254 

253 

500 

FF  1061 

76AFR 

1 

500 

288 

287 

500 

FF  1080 

76AFR 

19 

600 

244 

225 

600 

FF  1081 

76AFR 

100 

500 

280 

180 

500 

FF  1082 

76AFR 

200 

200 

FF  1084 

76AFR 

200 

200 

FF  1085 

76AFR 

100 

1 00 

FF  1089 

76AFR 

100 

100 

FFR  4 

76AFR 

185 

185 

LPD  15 

76AFR 

500 

50 

50 

500 

LPP  4 

76AFR 

500 

1 50 

1 50 

500 

LPH  2 

76AFR 

825 

1 50 

1 50 

825 

LSD  32 

76AFP 

76 

600 

200 

124 

600 

LSD  34 

76AFR 

400 

50 

50 

400 

LST  1190 

76AFR 

750 

235 

235 

750 

LST  1192 

76AFP 

600 

185 

185 

600 

LST  1193 

76AFP 

300 

85 

85 

300 

L'T  1194 

7AAFR 

400 

85 

85 

400 

j 

j 


385 


5HIP  FUNPINr-  ACTI''1TY 
PrFIOP  FMPIN’P  AHPUST  197S 
ATLANTIC  FLFFT 
Fl'NPINP  FCFNAPIO 

REPORT  FND  ?P30C1  DFC  If  1975 


HULL 

FNP, 

PYRYR 

CNTYP 

CNTPLN 

TOTFNP 

CmTYP 

FST 

FST 

ACT'rj  V 

FND 

. L' 

ALLYPS 

ALLYPS 

FND 

CNTYP 

THOP 

(1000) 

( 1 000) 

< 1 000) 

TOPTF 

TODTF 

PPMT 

OV/HL 

MSO 

4A3 

76AFP 

39 

39 

39 

39 

NSO 

A90 

76AFR 

39 

39 

39 

39 

PC  IPPl 

76AFP 

P5 

10 

1 0 

?5 

PC  9R 

76AFR 

25 

10 

10 

?5 

SSPN 

62B 

76AFP 

A36  A 

I 565 

1 665 

A36A 

S5PN 

f 30 

76AFR 

3016 

16? 

1 6? 

3016 

SSBN 

f31 

76AFP 

3066 

3015 

3015 

3066 

FSPN 

f 3A 

76AFR 

3517 

1 573 

1 573 

351  7 

SSRN 

f 35 

76AFP 

13'^9 

1 359 

376? 

SSBN 

63f 

76AFP 

3569 

1 351 

1 351 

3569 

SSN 

f07 

76AFF 

A 

A 

A 

A 

SSN 

f 1 A 

76AFP 

A550 

356P 

3558 

A550 

SSN 

615 

76AFP 

3550 

?607 

?607 

3550 

SSN 

637 

76AFP 

??3? 

8 

8 

??3? 

SSN 

638 

76AFP 

3398 

1 06 

106 

3398 

SSN 

6^6 

76AFR 

9 

8 

8 

9 

SSN 

6A9 

76AFP 

PPPl 

1 1 3? 

1 1 3? 

??81 

SSN 

663 

76AFR 

?8R0 

1 3P 

1 38 

?880 

SSN 

668 

76AFR 

91? 

9 1 ? 

91? 

91? 

SSN 

669 

76AFP 

1?06 

1P06 

1?06 

1 ?06 

SSN 

679 

76AFR 

1718 

1 07 

107 

1718 

1 7?3 

60899 

0 

?708? 

?5359 

60899 

PD  863 

76AFRR 

1 30 

1 30 

1 30 

1 30 

1 30 

DP  871 

76AFPP 

95 

1?5 

??0 

??0 

1?5 

1?5 

DD  883 

76AFPR 

91 

69 

1 60 

91 

69 

MSO  A33 

76AFPP 

39 

39 

39 

39 

39 

MSO  AA0 

76AFPR 

39 

39 

39 

39 

39 

MSO  509 

76AFPR 

39 

39 

39 

39 

39 

MSO  511 

76AFPR 

39 

39 

39 

39 

39 

PC  8A 

76AFRP 

10 

10 

10 

10 

10 

PC  88 

76AFFP 

10 

10 

10 

10 

10 

?HIP  Fl'NniNP  ACTIWITY 


PFPIOD  FNniNP  Aim'ST  I97S 
ATLANTIC  FLFFT 
FMNPINP  ?CFNAPIO 


RFPORT  FNP  SP3HP1  PFC  lA  197S 


HI  ILL 

FND 

PYRYR 

CMTYP 

CNTPLN 

TOTFNP 

CNTYP 

FST 

FST 

ACTUTY 

FND 

PLAN 

ALLYPS 

ALLYPS 

FNP 

CNTYP 

THOP 

( 10007 

( 1 000) 

(1000) 

TOPTF 

TOPTF 

PPMT 

OWHL 

AD  19 

76CFY 

63 

4000 

4063 

258 

195 

4000 

4063 

AE  2S 

76CFY 

205 

5000 

5205 

548 

343 

5000 

5205 

APF  3 

76CFY 

29  5 

3489 

3784 

375 

80 

3489 

3784 

AOE  A 

76CFY 

408 

9246 

9654 

731 

32  3 

9246 

9654 

AR  5 

76CFY 

53 

3203 

3256 

212 

1 59 

3203 

3256 

AS  3A 

76CFY 

500 

1 3202 

1 3702 

2000 

1 500 

1 3202 

1 3702 

AS  36 

76CFY 

125 

10596 

10721 

108 

10596 

1 072i 

ATF  162 

76CFY 

88 

1 193 

1281 

830 

740 

1 193 

1281 

DP  931 

76CFY 

20 

9227 

9247 

355 

335 

9227 

9247 

DD  933 

76CFY 

216 

11136 

1 1 352 

900 

684 

11136 

1 1 352 

DD  940 

76CFY 

193 

10231 

10404 

923 

730 

10231 

1 0424 

PD  943 

76CFY 

481 

9100 

9 581 

521 

40 

9100 

9581 

DDP  10 

76CFY 

436 

108  76 

11312 

9349 

8913 

10876 

11312 

DDP  19 

76CFY 

1 341 

1 1 500 

1 2841 

1 341 

1 1500 

12841 

DDR  23 

76CFY 

1313 

1008 

1 1394 

1 322 

9 

1 0081 

1 1 394 

DDR  38 

76CFY 

25 

487 

512 

307 

282 

487 

512 

DDP  4 

76CFY 

479 

1 1293 

1 1 772 

48  3 

4 

1 1293 

1 1 772 

FF  1068 

76CFY 

372 

8000 

8372 

378 

6 

8000 

8372 

FF  1072 

76CFY 

6 50 

6650 

7300 

5763 

5113 

6650 

7300 

FF  1075 

76CFY 

516 

6600 

71  16 

6067 

5551 

6600 

7116 

FF  1078 

76CFY 

335 

8417 

8752 

3 53 

18 

841  7 

8752 

FF  1079 

76CFY 

28  3 

8299 

8582 

337 

54 

8299 

85R? 

LPD  12 

76CFY 

275 

7823 

8098 

283 

8 

7823 

8093 

LPP  14 

76CFY 

416 

6291 

6707 

5821 

5405 

6291 

6707 

LPH  12 

76CFY 

208 

1 0 4.3P 

1 0640 

558 

350 

104,32 

10640 

LPH  9 

76CFY 

2058 

7770 

9828 

8171 

6113 

7770 

9828 

LSD  29 

76CFY 

530 

5460 

5990 

5565 

5035 

5460 

5990 

LSD  38 

76CFY 

200 

7100 

7300 

200 

7100 

7300 

LST  1181 

76CFY 

680 

3851 

4531 

4477 

3797 

3851 

453; 

LST  1188 

76CFY 

250 

4930 

5180 

730 

480 

49  30 

5180 

MSO  448 

76CFY 

500 

500 

1 000 

539 

39 

500 

1 000 

PC-  86 

76CFY 

30 

482 

512 

1 55 

125 

482 

512 

PR  87 

76CFY 

29 

48  5 

514 

204 

1 75 

485 

514 

SSPN  629 

76CFY 

2689 

35274 

37963 

7696 

5007 

35274 

37963 

SSN  605 

76CFY 

1 307 

30084 

31391 

5315 

4008 

30084 

31391 

CSV  ApA 

76CFY 

3358 

29200 

32558 

31061 

27703 

29200 

32558 

SSN  650 

76CFY 

3787 

23690 

27477 

5096 

1 309 

23690 

27477 

SSN  653 

76CFY 

5 58  7 

32990 

38577 

1 1 593 

6006 

32990 

38577 

SSN  660 

76CFY 

241  1 

23744 

26155 

49  1 8 

2507 

23744 

26155 

SSN  661 

76CFY 

1580 

29164 

30  744 

1 787 

. 207 

29164 

30744 

SSN  675 

760FY 

2713 

1 9236 

21949 

12717 

1 0004 

19236 

21949 

SSN  678 

76CFY 

929 

2100 

3029 

936 

7 

2100 

3029 

387 


?H1P  RINPINC  APTIPITY 


PFPior  FNriNr  aiti'ft  19?s 


ATLAN’TIC  FLFFT 


FPN'PIMA  FPFNAPIO 


PFPORT  FND  SCI3PP1 


PFC  lA  1979 


HULL 

FNP 

PYPYR 

PNTYF 

CNTPLN 

TOTFND 

DNTYR 

FST 

FST 

ACTV'TY 

FNP 

PLAN 

ALLYFS 

ALLYR9 

FNP 

CNTYP 

THOR 

< 108(5) 

( 1 000) 

( 1 OOP) 

TOPTF 

TOPTF 

PPMT 

Ol'HL 

3793A 

AA33S9 

A903A A 

1 A1 300 

1 033AA 

ASPA3? 

A903A1 

PD  8?I 

7ACFYP 

7S 

S?S7 

9 /I  /1 0 

AA  1 0 

AA?7 

SPS7 

SAAO 

PD  PPP 

7ACFYP 

90 

A979 

AAA9 

90 

A579 

AAA9 

PP  8A? 

7APFYR 

PR 

SP9S 

9383 

1 30 

A? 

9?95 

S3R3 

PP  BAA 

7ACFYP 

1 

A7RA 

ASP? 

1 A A 

90 

A38  A 

ASP? 

j DP  8BP 

7ACFYP 

SO 

9307 

5378 

3008 

?937 

9307 

5378 

j LPA  PA9 

7ACFYP 

S3P 

ASPS 

70A3 

738 

POO 

ASPS 

79AA 

1 MSP  A31 

7ACFYP 

3S 

5RA 

A?1 

SS9 

S?0 

SRA 

API 

1 f^SO  AAl 

7ACFYP 

9R1 

98  1 

39 

39 

S8  1 

581 

A MSP 

7ACFYR 

A9A 

A9A 

39 

39 

A9A 

A9A 

j MSO  AAA 

7ACFYP 

S 

SAP 

SAS 

A 38 

A33 

SAP 

SAS 

; “SO  ASA 

7ACFYP 

1(5 

A3A 

AAA 

3A0 

3S0 

A3A 

AAA 

j PP  B9 

7ACFYP 

A3? 

A3? 

?5 

PS 

A3? 

A3? 

i 

89? 

3 AB?0 

3S99A 

1 01  9F 

90A? 

3ARP0 

3A877 

■ AFS  ? 

7ACOP 

3?R7 

800 

3 78  7 

359 

SOP 

3 78  7 

* A A SPP 

7ACOR 

A3(5 

A3 

A73 

A/iO 

1 3 

A3 

A73 

AT-  521 

7APOP 

SS(5 

30 

580 

30 

980 

i AO  99 

7AC0P 

A199 

A9 

A?A  A 

ixiA 

AS 

AS 

A?AA 

j AOF  P 

7ACOP 

A3AR 

A3AR 

A3A8 

3 APS  A 

7AC0P 

709 

9S 

8(5A 

77^ 

AS 

9S 

80A 

j rn  3A 

YACn” 

7A71 

AOO 

8(571 

77S5 

8A 

AOO 

8071 

CM  AA 

7AC0R 

309  70 

S3 

310?3 

m 0P7 

S3 

S3 

310P3 

DP  937 

7ACOP 

7AS8 

1 ?P 

7778 

IPO 

7778 

1 PP  938 

7ACOP 

7R?? 

A7 

7RA9 

7PAR 

AA 

A7 

7RA9 

1 PP  9A1 

7AP0P 

A9A0 

1 50 

7090 

700-fl 

AA 

1 90 

7090 

j PPP  17 

7ACOR 

ROAR 

?0 

R08R 

ROR  7 

19 

?0 

8088 

1 ppr,  ? 

7AC0P 

7SA7 

AOO 

79A7 

7SA7 

AOO 

79A7 

! DPP  3 

7AC0P 

A1  A 

300 

71  A 

A 

300 

71  A 

’ PPP  AS 

7APOP 

7?B  A 

AOO 

788  A 

7iSl  0 

IPA 

AOO 

78PA 

i FF  1P3R 

7Aror 

39?  3 

?0 

39  A3 

79P7 

?0 

39  A3 

: FF  1PS9 

7ACOP 

9975 

ytp.o 

A 3 79 

R977 

? 

AOO 

A379 

j FFP  S 

7Arnp 

A70A 

A7PA 

A70/^ 

A70A 

^ FFP  A 

7APOP 

A9SA 

1 90 

71  OA 

A9R7 

?7 

1 90 

710A 

I.PP  1 

7Acnp 

HOP  1 

^0 

8 1 ?1 

R1  ?1 

AO 

AO 

81P1 

L^p  3P 

871  A 

1 30 

80/iA 

P7/iP 

3? 

1 30 

88  AA 

388 


SHIP  Fl'NDINP  ACTIVITY 


PFPIOD  FNDINP  AI'CnST  197P 
ATLANTIC  FLFFT 
Fl'NDINP  SCFNARIO 

REPORT  FND  SPI300I  PFC  I A 197^ 


HULL 

FND 

PYRYP 

CNTYP 

CNTPLN 

TOTFND 

CNTYP 

FST 

FST 

ACTVTY 

FND 

PLAN 

ALLYPS 

ALLYPS 

FND 

CNTYP 

THOP 

(1000) 

( 1 000) 

( 1000) 

TODTF 

TODTF 

RPMT 

0\/HL 

LSD 

37 

76COR 

4722 

260 

498? 

488? 

1 60 

260 

498? 

LST 

1 180 

76COR 

4491 

90 

4581 

4561 

70 

90 

4581 

PG 

93 

76C0R 

625 

27 

652 

6 3? 

7 

27 

65? 

SSN 

55  5 

76COR 

28404 

544? 

33846 

31704 

3 300 

544? 

33846 

SSN 

591 

76COR 

30497 

3443 

33940 

3150? 

1 005 

3443 

33940 

SSN 

604 

76COR 

22800 

900 

23700 

23204 

404 

900 

23700 

SSN 

664 

76C0R 

16815 

4 

16819 

16819 

4 

4 

16819 

SSN 

670 

76COP 

21234 

19 

21253 

21253 

1 9 

19 

21253 

SSN 

674 

76C0F 

20306 

377 

20683 

20319 

1 3 

377 

20683 

SSN 

676 

76Cnp 

16139 

1 500 

1 7639 

16145 

6 

1 800 

1 7639 

♦ ♦♦SlipTOTAL*** 

306507 

1 5605 

3221  1 2 

312476 

5969 

1 8608 

32? 1 1? 

DD 

P?7 

76C0PP 

4709 

50 

4759 

47  1 9 

10 

50 

4759 

PD 

890 

76ror-p 

4053 

55 

4 108 

4108 

58 

55 

4108 

MSO 

4?9 

76C0PF 

502 

49 

551 

551 

49 

49 

551 

***5»tPT  'T 

9264 

1 54 

9418 

9 3 38 

1 1 4 

1 54 

9418 

CV 

4? 

76SPA 

437 

5204 

5641 

3667 

3230 

5204 

CV 

59 

76SRA. 

800 

59  30 

6 730 

2300 

1 500 

5930 

CV 

60 

765RA 

1312 

6977 

8289 

8289 

69  7 7 

6977 

CV 

62 

76SRA 

49 

7905 

7954 

167 

118 

7908 

CV 

67 

76FPA 

1 50 

^984 

6134 

385  ' 

235 

5984 

C'/T 

16 

76  SPA 

2561 

2561 

200 

200 

2561 

SSPN  A33 

76SPA 

919 

2978 

389  7 

354? 

2623 

2978 

SSPN  A43 

76SPA 

4078 

4078 

500 

500 

4078 

SSN 

68? 

768FA 

2889 

2889 

691 

691 

2889 

SSN 

683 

76SPA 

215? 

21  52 

223 

223 

218? 

***«:npTnT^L*** 

36  4 7 

1 9964 

16297 

46688 

0 

n'VniNf:  SCFNAPIO 


PFPORT 

FND  5PI30P)1 

DFC 

lA  197S 

HULL 

FNP 

PYRYP 

CNTYP 

r.NTPLN 

TOTFND 

CNTYP 

FFT 

FPT 

ACTVTY 

FND 

PLAN 

ALLYPP 

ALLYP? 

FND 

CNTYP 

THDP 

( tPlDO) 

( 1 

( 1 PIPIPI) 

TODTF 

TDPTF 

PPMT 

o\/hl 

*****total* 

*** 

3A1  t»0/i 

AP199S 

I APP9P 

A1 IPAP 

PP9P99 

i 


VOULD  YOU  LIKE  TO  SUBMIT  ANOTHER  OUFRY?-  YES 


PLEASE  INPUT  OUFRY  COMMANOS 
OUERY  S03 

IF  ASOFDATE  IS  TSOBSl  AND  PREFIX  ENDATE  IS  76? 
REPORT  FLT 

HEAP  I SSCHFDULF  FOP  RETURN  TO  THF  FLEETS 
HEAD  2 JFUNDINC  INFORMATION  ONLY? 

HEAD  3 SFUNDINO  SCENARIO? 

SEND 

YOUR  OUERY  HAS  BEEN  ACCEPTED 
?A 


USER  ABORT 

OUERY  RUN  ABORTED  IN  ROUTINE  SCPN 

WOULD  YOU  LIKE  TO  SUBMIT  ANOTHER  OUFRY?-  YES 

PLEASE  INPUT  OUFRY  COMMANDS 
OUERY  S03 

IF  ASOFDATE  IS  7S0831  AND  PREFIX  ENDATF  IS  76? 
REPORT  FLT 
SORT  ON  ENDATF 

HEAD  1 SSCHFDULE  FOR  PETI.iRN  TO  THF  FLEET? 

HEAD  2 SFtiNDINO  INFORMATION  ONLY? 

HEAD  3 SEUNDINF  SCENARIO? 

SEND 

YOUR  OUFRY  HAS  BEEN  ACCEPTED 


FOR  EACH  PUESTION/  TYPE  IN  P,  T.  OR  P, 


OUERY  S03,  OUESTION  NO.  t.  HAS  S3  HITS-T 


j 


i 


( 

f 


i 


1 


391 


SHIP  SCHFnuLF  FFPnPT 


SCHFPULF  Fnp  PFTI'PN  TP  THF  FLFFT 
Fl'NDINP  INFORMATION  ONLY 
FUNPINP  SCFNAPIO 


RFPORT  FLT  SC'3f'PI 


END 

DATE 


START 

PATF 


HULL 


SHIP 


YAPP 


PFC  lA  I97S 


OVHL 


JAN 

76 

Al'C 

75 

LSP  29 

PLYMOUTH  POCK 

5 

100 

m 

JAN 

76 

APR 

75 

FFC  5 

PACE 

PH 

100 

JAN 

76 

JAN 

75 

SSN  676 

PILLFI SH 

PT 

100 

FEP 

76 

OCT 

75 

C'/  59 

FOPPFSTAL 

N 

FEB 

76 

AIT, 

74 

SSN  591 

SHARK 

SP 

100 

FEB 

76 

JUL 

75 

LPH  9 

CAM 

PH 

100 

FEB 

76 

NOV 

75 

PC-  S9 

marathon 

9 

100 

FEP 

76 

AUC 

75 

PP  821 

JOHNSTON 

3 

100 

MAP 

76 

FEP 

76 

CVT  16 

LFXINCTON 

SJ 

MAR 

76 

MAY 

75 

PPC-  3 

KINC 

N 

100 

MAP 

76 

NOV 

75 

ATF  162 

SHAKOPI 

5 

100 

! 

MAP 

76 

AUC 

75 

LST  1181 

Sl'MTFP 

5 

100 

MAR 

76 

JUL 

75 

FF  1072 

PLAKFLY 

C 

100 

1 

APR 

76 

NOV 

75 

LPA  249 

MAP  I ON 

3 

100 

APR 

If, 

A'.IP 

75 

LPD  1 4 

TRENTON 

5 

100 

APR 

76 

■JAN 

76 

PC  86 

ANTELOPE 

NFLM 

100 

APR 

76 

JAN 

76 

PC  87 

PFADY 

NFLM 

100 

1 APR 

76 

SEP 

75 

PP  880 

PYFSS 

3 

100 

1 APR 

76 

APP 

75 

CC  34 

PIPPLF 

BA 

100 

' 1 

1 MAY 

76 

FFP 

76 

CV  6 7 

KENNEDY 

■ i 

1 MAY 

76 

APR 

75 

PDC  45 

PFV’FY 

C 

100 

JI'N 

76 

JAN 

76 

AD  19 

YOSFMITF 

SJ 

100 

JPN 

76 

AUC 

75 

PDC  23 

PYPP 

N 

100 

Jl'N 

76 

MAP 

76 

SSN  661 

LAPON 

VN 

1 00 

JI'N 

76 

MAP 

76 

AC-F  3 

LA  SALLE 

SUPIC 

100 

JUN 

76 

APR 

76 

SSN  683 

PAPCHF 

N 

Jit 

76 

JUL 

74 

SSN  525 

SKIPJACK 

sc 

100 

» 

JI'L 

76 

MAY 

76 

SSPN  643 

BANCROFT 

sc 

, i 

JUL 

76 

JUL 

75 

SSN  675 

PLi'FFISH 

N 

100 

i 

J'.'L 

76 

APR 

76 

FFAFLFSS 

6 

1 00 

• i 

Al'P 

76 

OCT 

75 

PDC  19 

TATTNALL 

C 

100 

~f 

AfT 

76 

MAY 

76 

MSO  441 

EXULTANT 

3. 

100 

t 

1 

AIT- 

76 

JAN 

76 

AR  5 

VULCAN 

s 

100 

i 

Al'P 

76 

FEP 

76 

LSD  38 

PENSACOLA 

5 

100 

A UP 

76 

FFB 

76 

LST  1188 

SACINAK 

e; 

100 

- 1 

A nr- 

76 

OCT 

75 

FF  1075 

TPIPPF 

c 

100 

, ; 

SEP 

76 

MAY 

76 

CV  62 

INDFPFNDFNCF 

N 

I 

* I 

SEP 

76 

JAN 

76 

CANOPUS 

C 

100 

: 4 

PATA  BASF 

- PA 

'«?■? 

SFP 

76 

Ji  'N 

76 

MSO  4^8 

ILLUSIVE 

100 

: ' 

SEP 

76 

DFC 

75 

AF  28 

SANTA  FAPPAFA 

SJ 

100 

r • 

76 

APP 

76 

PD  866 

CONE 

SJ 

1 00 

r 

SFP 

76 

OCT 

75 

PD  943 

PLANPY 

3 

100 

OCT 

76 

NO\’ 

75 

PPC  1 0 

c/^MFSON 

PH 

' .* 

OCT 

76 

APP 

76 

SPFAP 

N 

100 

OCT 

76 

MAP 

76 

LPP  12 

SHPFVFPOFT 

5 

100 

' 

OCT 

76 

MAY 

76 

PP  822 

MCCAPP 

SJ 

100 

ki 

U i 
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SHIP  SCHFPULF  RFPOPT 


SCHEDI'LF  FOP  RFTI'FN  TO  THF  FLFFT 
FONDINP  INFOPNiPTlON  ONLY 
Fl'NDINr-  SCENARIO 


RFPOPT  FLT  S030P1 


OFC  If  1975 


END 

DATE 

START 

DATE 

HtiLL 

NOV 

76 

DFC 

75 

DDO  A 

NOV 

76 

NAY 

76 

LPH  IP 

NOV 

76 

DFC 

75 

FF  106P 

DEC 

76 

JUL 

76 

APS  A1 

DEC 

76 

MAY 

76 

DD  PA? 

DEC 

76 

JAN 

76 

on  933 

DEC 

76 

JAN 

76 

DD  9 API 

SHIP  YAPO 

OVHL 


LAP'PFNCF 

N 

I PIPI 

INCHON 

• 

lOPi 

VPFFLAND 

PH 

lf»PI 

OPPOFTMNF 

5 

FISKF 

3 

IPIPi 

PAPPY 

PH 

100 

MANLFY 

PH 

IPPI 

CINCLANTFLT 

Ship  Funding  Profile  Scenario 
Terminal  Session  and  Report  Samples 


1 

i 

J 


! 


{ 


Attachment  #5 
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NSFPC  ATPP  IMTFPCnM  V'^.P 
PATF  IP/17/7S 
TIMF  J7.13.PP. 


PLFPSF  LOP  IN 

lopin.piu-'fvfavfp,  i jppuppppp.  , pi'p 

CONMANP-  FTL»SPP 
CONMANP-  COMPAPF. SHARP 


rONPAPF 


1 3. 1 3.  il7. 
lP/1 7/7S 


SHARP  SMPSYSTFM  fnTFPFP 
????  PFPPFF 


PLFASF  INPI'T  PFPOFT  PFFINJTIONF. 

IP  PASFP 
PFPOPT  PRO 

NHFAP  SSHIP  FMNPINP  PPOFILFF 
COL  HFAD  1 = TASOF/PATFf 
COL  HFAP  P = SHHt.Lf 
COL  HFAP  3 = fFNP/ACTVTYS 
COL  HFAP  S = SSTAPT/PATFS 
COL  HFAP  A = «FNP/PATF« 

COL  HFAP  7 = SFNP/PPIOP/yFAPS 
COL  HFAP  « = FFNP/CNT/YFART 
COL  HFAP  P = FFST/CNTYP/RCHT* 

COL  HFAP  IP  = cfct/thof/0\/HL» 

r-FINT  ASOFPATF,  HI'LL.  F^’PA^T^'TY.  FTArTPATF,  FNPATF,  PYFYFFNP, 

CNTYRFNF’.  FSTPNTVPrT,  pSTOVHL 

JFNP 


PFPOFT  PFFINITION  FPPOR  cumHAFY 


IP  - PASFP 


PFPOPT  - PFO 

NO  FPPOPS  FOIINP  - FFPOPT  PFFTNITFON  ACCFPTFP 
????  FFPPFF 
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r.  V,-j» 


PI.FA5F  IN'Pl'T  PPPnpT  prPIMITnvP. 

IP  P^iFF? 

PFPPFT  YPP 

MHFAP  FYAPP  Fl'NPIN'F  I MFPPM  AT  I r»MF 

rOL  HFAFP  1 = FYAPr» 

mu  HFAP  ? = FPHI.LT 

CPU  HFAP  P = FFTAPT/PATFF 

rOL  HFAP  -4  = ?FNP/rATF« 

rOL  HFAP  “i  = «FNP/ArT\/TY» 

rOL  HFAP  fi  = »F\'n/ppinp/YFAP« 

COL  HFAP  7 = FrMT/YfAP/FN'PPF 
COL  HFAP  P = TTPTAI./ALI.YF/FPPFF 

PRINT  FCLTY.  PI'LL.  FTAPTPATF.  FMPATF.  FNPAFT'/TV,  pvPYPPMP. 

CNTYPFNP.  TOTF^'P 

JFNP 


PFPOPT  PFFINITION  FPFOP  pliMMppy 
IP  - PAFF? 


PFPOPT  - YPP 

NO  FFPOPP  FAI'NP  - PFPnpT  riPFINITinv  pfTPPTFP 
? ???  PFPPPF 


4 


I 

I ’ 


396 


YOU  HAVF  SFLFCTFn  THF  INTFP^'CTIVF  ruFPY  OPTION 


VOULD  YOU  LIKF  AN  FXPLPNATION  OF  THF  SYFTFM?-nO 


SFLFCT  ONF  OF  THF  FOLLOVINP  PPTA  PAFF? 
18  LOPISTICS  noCl'MFNT  DATA  PANX 
31  YL'PSO  DATA  RANK 
3?  HKPS-PAFF-? 

??  3? 

PLtASF  INPUT  PUFPY  rON«ANPF 
PUFPY  **♦ 

IF  ASOFDATF  IS  7SR131 

AND  FNDACTV/TY  IS  7SCFY 

AND  PPFFIX  STARTDATF  IS  75R1 ? 

PRINT  HULL  AND  SHIP 

HFAD  1 rjANUAPY  I97S  STARTS* 

HFAD  ? STHF  PRFAT  SHIP  SCFNAPIOT 
SFND 

YPUP  PUFPY  HAS  RFFN  ACXFPTFP 


FOP  FACH  PUFSTION,  tYPF  IN  p,  T»  OP  p. 

PUFPY  ***,  PUFSTION  NO.  ].  HAS  7 HITS 


I 


\ 


i 

j 


1 
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JANl'APY  I97S  PTAPTP 


RFPOPT  DPT 


THF  r-PFAT  ?HIP  PCFNAPIO 


PFr  n 197S 


HMLLt  DDP  ? 
SHIP:  APAMS 


HI'LLrFFP  A 
SHIP:  FIIPFP 


HULL:  SSN  A7A 
SHIP:  PILLFISH 


HI'LL:  lst  nspi 

SHIP:  MANITOVOC 


HPLL:  PP  9P 
SHIP:  PPAND  PAP  I PS 


HULL:  PP  10P 
SHIP:  POMPLAS 


HI'LL:  DP  937 
SHIP:  PAVIS 
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WOULD  YOU  I-IKF  TO  FURMIT  ^'MOTHrr  OUrpY?-  YFF 


i 

I 

i 

I 


PLFAFF 


INPUT  PUFRY  CUMMANDS 


PUFPY  *1* 


IF  HULL  IS  DPR  ? OR  FFR  A OR  SSM  A7A  OP  I.FT  IIRP  OP  PR  9R  OP 
PR  IPIP)  OP  DD  937 

AND  ASOFPATF  IS  PF  TO  7AP731 /7SPR31 
AND  SUFFIX  FNDACTV'TY  IF  NF  TO  PORT? 

PFPORT  PPO 

SORT  ON  HULL  ANO  AFOFDATF 
HFAD  1 FJANUAFY  197F  FTAPTSF 
HFAD  P 5THF  RPFAT  SHIP  SCFNAPIOf 

HFAD  3 STHIF  IS  HOV  WF  FUND  THFM  AND  FIND  THFMS 
SEND 


YOUR  PUFPY  HAS  FFFN  ACCFPTFD 


-•/ 

I 


M 


FOR  FACH  PUFFTION,  TYPF  IN  D,  T.  PR  P. 

PUFPY  *1*.  PI'FFTION  no.  1,  HAS  9A  HITS-T 


SHIP  FltNniNP  PPOFILF 


JANPAFY  197S  «;tAPTF 
THF  FPFAT  SHIP  SCFNAPIO 
THIF  IF  HOV'  l.'F  Ft'Nn  THFM  AN'P  FINP  THFM 


PFPOPT  PPO 

*1*PP1 

ASOF 

HULL 

FND 

START 

DATE 

ACTVTY 

DATF 

JUL 

31 

7A 

PD  937 

75CFY 

JAN 

75 

Al.T- 

31 

7^ 

PD  937 

75CFY 

JAN 

75 

FFP 

3P 

74 

DP  937 

75CFY 

JAN 

75 

OCT 

31 

74 

PP  937 

75CFY 

JAN 

75 

NOV 

30 

74 

PD  937 

75CFY 

JAN 

75 

DFC 

31 

74 

PD  937 

75CFY 

JAN 

75 

JAN 

31 

75 

DP  937 

75CFY 

JAN 

75 

FFP 

?8 

75 

PP  937 

75CFY 

JAN 

75 

MAR 

31 

75 

PD  937 

75CFY 

JAN 

75 

APR 

30 

75 

PD  937 

75CFY 

JAN 

75 

MAY 

31 

75 

PP  937 

75CFY 

JAN 

75 

JUN 

30 

75 

PP  937 

75CFY 

JAN 

75 

JI'L 

31 

75 

PP  937 

7AC0P 

JAN 

75 

Alip 

31 

75 

PP  937 

7AC0P 

JAN 

7'; 

JUL 

31 

74 

DPP  ? 

75CFY 

JAN 

75 

A Up 

31 

74 

PPP  ? 

75CFY 

JAN 

75 

FFP 

30 

74 

PDP  ? 

75CFY 

JAN 

7P 

OCT 

31 

74 

PDP  ? 

75CFY 

JAN 

75 

NOV 

30 

74 

PDP  ? 

75CFY 

JAN 

75 

JAN 

31 

75 

PPP  ? 

7PCFY 

JAN 

75 

FEB 

?B 

75 

PPP  ? 

75CFY 

FFP 

75 

MAP 

31 

75 

PDP  ? 

75CFY 

FFP 

75 

APR 

30 

75 

PPP  P 

7 50FY 

FFP 

7P 

MAY 

31 

75 

PPP  ? 

75CFY 

FTP 

75 

JUN 

30 

75 

POP  P 

75CFY 

FFP 

7P 

JUL 

31 

75 

PDP  P 

7AC0P 

FFP 

75 

Aun 

31 

75 

PPP  ? 

7 A COP 

FFP 

75 

JIT. 

31 

74 

FFP  f 

75CFY 

JAN 

75 

A UP 

31 

74 

FFP  6 

75CFY 

JAN 

75 

SFP 

30 

74 

FFP  A 

75CFY 

JAN 

7 5 

NOV 

30 

74 

FFP  A 

75CFY 

JAN 

7P 

PFO 

31 

74 

FFP  A 

75CFY 

JAN 

75 

JAN 

31 

75 

FFP  A 

7 5CFY 

JAN 

75 

FEB 

?B 

75 

FFP  A 

75CFY 

JAN 

75 

MAP 

31 

75 

FFP  A 

75CFY 

JAN 

75 

APP 

30 

75 

FFP  A 

75CFY 

JAN 

75 

MAY 

31 

75 

FFP  A 

75CFY 

JAN 

75 

J"N 

30 

75 

FFP  A 

75CFY 

JAN 

JUL 

31 

75 

FFP  A 

7AC0R 

JAN 

75 

AUP 

31 

7 5 

FFP  A 

7AC0F 

JAN 

75 

JUL 

31 

74 

LST  IlPO 

75CFY 

JAN 

75 

AUP 

31 

74 

L5T  IlPO 

7 5CFY 

JAN 

75 

FFP 

30 

7 4 

L?T  IlPO 

75CFY 

JAN 

7*= 

OCT 

31 

74 

LET  IlPO 

75CFY 

IAN 

7P 

vov 

->p 

74 

L5T  IIPP 

7ACPY 

JAN 

7^ 

PFP  J7  197F 


FNP 

FNP 

FNP 

FST 

FST 

PATF 

PRIOP 

CNT 

CNTYP 

THOP 

YFAP 

YFAP 

POMT 

OVHL 

5FP 

75 

1 SO 

1 000 

7930 

8080 

?FP 

75 

150 

1 000 

8330 

8480 

5FP 

75 

1 50 

1 000 

8330 

8480 

SFP 

75 

1 50 

4197 

8330 

8480 

SFP 

75 

1 50 

4197 

8330 

8 480 

SFP 

75 

1 50 

4443 

8330 

8480 

SFP 

75 

1 50 

4443 

78  30 

7980 

DFC 

75 

1 50 

444P 

7830 

7980 

PFC 

75 

1 50 

4471 

7830 

7980 

PFC 

7S 

1 50 

7030 

7830 

7980 

DFC 

75 

1 50 

708  3 

7730 

7880 

DFC 

75 

1 50 

7408 

7508 

7458 

PFC 

75 

7f,5P 

IPO 

7778 

DFC 

75 

74  50 

IPO 

7778 

NOV 

75 

40  5 

788P 

8P87 

NOV 

75 

405 

9 48P 

9887 

NOV 

7'V 

405 

PO 

948P 

9887 

NOV 

75 

405 

?0 

908P 

9487 

NOV/ 

75 

405 

4OP0 

908P 

9 48  7 

NOV' 

75 

405 

50P0 

788P 

8?87 

PFC 

75 

405 

sopo 

788? 

8P87 

PFC 

75 

405 

50PO 

8040 

8445 

DFC 

75 

405 

7080 

8040 

8445 

PFC 

75 

405 

7PP7 

8040 

8445 

PFC 

75 

405 

7584 

7484 

7989 

PFC 

75 

79P9 

^00 

8389 

PFC 

75 

7547 

400 

7947 

SFP 

75 

350 

1 POO 

7110 

7440 

SFP 

75 

350 

1000 

7110 

7440 

SFP 

75 

350 

1018 

7110 

7440 

OCT 

75 

350 

5579 

7110 

7440 

OCT 

7S 

350 

4479 

7010 

7340 

OCT 

75 

350 

5579 

701  0 

7340 

NO'/ 

7*: 

3 50 

5875 

7010 

7340 

NO'/ 

75 

350 

4980 

7010 

7340 

NOV/ 

75 

340 

4 390 

7010 

7340 

NO'/ 

75 

350 

4404 

4910 

7P40 

NOV/ 

7S 

350 

4404 

4404 

4954 

OCT 

75 

4954 

1 1 

1 1 

4947 

OCT 

75 

4954 

P7 

1 50 

7104 

MAY 

75 

540 

4?43 

4803 

MAY 

75 

440 

POO 

4043 

4803 

JI'V 

7S 

440 

poo 

4?  43 

4803 

. n 'N 

7S 

540 

34«0 

4P59 

48  19 

J''V 

7": 

440 

3480 

4?«<5 

48  1 9 

400 


c;m  r pi'MrjN'f  i’rocii.r 


JPM\>PPY  I9TS  FTAFTP 


THF  PRFAT  SHIP  SCFNAPIO 


THIS  IS  HOV  V'F  Fl'NP  THFM  AN'P  FINP  THFM 


RFPORT  PRO  *1*001 


PFC  n 197*i 


ASOF 

HULL 

FND 

START 

FND 

FND 

FND 

FST 

FST 

DATE 

ACTVTY 

DATF 

DATF 

PRIOR 

CNT 

CNTYP 

THOR 

YFAP 

YFAP 

PPMT 

OVHL 

DEC 

31 

7A 

LST 

1 1B0 

75CFY 

JAN 

75 

JUN 

75 

9R0 

3580 

4519 

5079 

JAN 

31 

75 

LST 

1 180 

7 5CFY 

JAN 

75 

Jl'N 

75 

9R0 

3580 

4084 

4544 

FEP 

?S 

75 

LST 

1180 

75CFY 

JAN 

75 

JUN 

75 

550 

3580 

4084 

4544 

MAP 

31 

7-5 

LST 

1 180 

75CFY 

JAN 

75 

Jl'N 

75 

5A0 

3880 

448  4 

5044 

APR 

30 

75 

LST 

1 180 

75CFY 

JAN 

75 

J"L 

75 

550 

4390 

4 48  4 

5044 

MAY 

31 

75 

LST 

1 180 

75CFY 

JAN 

75 

Jl'L 

75 

550 

4390 

4 48  4 

5044 

Jl'N 

30 

75 

LST 

1 180 

75CFY 

JAN 

75 

JUL 

75 

550 

4405 

4405 

4955 

JL'L 

31 

75 

LST 

1 180 

7AC0R 

JAN 

75 

Al'P 

75 

4955 

70 

90 

5059 

AUG 

31 

75 

LST 

1 180 

76C0R 

JAN 

75 

AUG 

75 

4491 

70 

90 

4581 

Jl.'L 

31 

7A 

PP 

100 

75CFY 

JAN 

75 

MAR 

75 

10 

P5 

5P5 

935 

AUG 

31 

7A 

PP 

1 00 

75CFY 

JAN 

75 

MAP 

75 

10 

50 

5?  5 

535 

SEP 

30 

7A 

PG 

100 

75CFY 

JAN 

75 

MAP 

75 

10 

50 

5?5 

535 

OCT 

31 

7A 

PG 

1 00 

75CFY 

JAN 

75 

MAP 

75 

10 

350 

5?5 

535 

NOV 

30 

7A 

PG 

I 00 

75CFY 

JAN 

75 

MAP 

75 

1 0 

350 

5?5 

935 

DEC 

31 

7A 

PG 

1 00 

75CFY 

JAN 

75 

MAR 

75 

10 

450 

5P5 

535 

JAN 

31 

75 

PG 

1 00 

7 5CFY 

JAN 

7*' 

MAP 

75 

10 

475 

5P1 

531 

FFP 

?8 

75 

PG 

1 00 

75CFY 

JAN 

75 

MAR 

75 

10 

475 

505 

515 

MAP 

31 

75 

PP 

100 

75CFY 

JAN 

75 

MAP 

75 

10 

48  5 

505 

515 

APR 

30 

75 

PP 

100 

75CFY 

JAN 

75 

APF 

75 

10 

48  5 

505 

915 

MAY 

31 

75 

PG 

100 

75CFY 

JAN 

75 

APR 

75 

1 0 

48  9 

48  5 

495 

JUN 

30 

75 

PP 

100 

75CFY 

JAN 

75 

APR 

74 

10 

48  7 

48  7 

497 

AUG 

31 

75 

PG 

1 00 

7AAFP 

1 0 

?5 

Jl'L 

31 

7A 

PG 

98 

75CFY 

JAN 

75 

MAP 

75 

10 

?5 

491 

501 

AUG 

31 

74 

PG 

98 

75CFY 

JAN 

75 

MAP 

75 

1 0 

50 

491 

501 

SEP 

30 

74 

PG 

98 

7 5CFY 

JAN 

75 

MAP 

79 

10 

50 

491 

501 

OCT 

31 

74 

PP 

98 

75CFY 

JAN 

75 

MAR 

79 

10 

350 

491 

501 

♦ *#  VHO  IS  RIINNINP  PV'S  JOPS. 
**.  PHO  IS  Pl'NNlNP  PVS  jnps. 
**,  '•■HO  IS  Pl'NNlNP  PV'S  JOPS. 
**.  VHO  IS  Pl'NNlNP  PV'S  JOPS. 
**,  V’HO  IS  Rl'NNINP  PV'S  JOPS. 
**.  VHO  IS  Rl'NNINP  PV'S  JOPS. 

♦ '•'HO  IS  Pl'NNlNP  P'-'S  JOPS. 

♦ *.  VHO  IS  Pl'NNlNP  PV'S  JOPS. 


NOV 

30 

74 

PP 

98 

75CFY 

JAN 

75 

MAP 

75 

1 0 

35  0 

491 

501 

DFC 

31 

74 

PP 

98 

75CFY 

JAN 

75 

MAR 

75 

10 

440 

491 

501 

JAN 

31 

75 

PG 

98 

75CFY 

JAN 

75 

MAP 

75 

1 0 

504 

5?1 

531 

FEB 

?8 

75 

PP 

98 

75CFY 

JAN 

75 

MAP 

75 

10 

905 

909 

515 

MAP 

31 

75 

PG 

98 

75CFY 

JAN 

75 

MAR 

75 

1 0 

495 

505 

515 

APR 

30 

75 

PP 

98 

75CFY 

JAN 

75 

APR 

75 

1 0 

48  5 

495 

515 

MAY 

31 

79 

PP 

98 

75CFY 

JAN 

79 

APP 

75 

1 0 

495 

49  5 

515 

Jl'N 

30 

75 

PG 

98 

75CFY 

JAN 

75 

APF 

75 

10 

499 

495 

505 

AUG 

31 

75 

PG 

98 

75AFP 

10 

P5 

Jl'L 

31 

74 

SSN  575 

75PFY 

JAN 

75 

JAN 

75 

1930 

1P594 

1 5585 

AUG 

31 

74 

SSN  575 

75CFY 

JAN 

75 

JAN 

75 

1930 

1 P594 

1 5985 

I jANI'^PY  197S  5TAPTF 

i THP  r-PFAT  FHIP  FCFNAPIO 


THIS 

: tP  HOI.'  PF 

nfNP 

THFM 

ANP 

FINP  THFM 

RFPORT 

PPO 

♦1*001 

PFC 

17  1975 

ASOF 

HPLL 

FNP 

5TAFT 

FNP 

FNP 

FNP 

F5T 

F5T 

DATF 

ACTVTY 

PATF 

PATF 

PRIOR 

CNT 

CNTYP 

THPP 

YFAP 

YFAP 

PPMT 

PVHL 

MAY  31 

75 

5SN 

f.76 

75CFY 

JAN 

75 

JAN 

If. 

1930 

1 PAOO 

1 1900 

1 5P3? 

JUN  30 

75 

SFN 

f 7A 

75CFY 

JAN 

75 

JAN 

If 

1 930 

1??07 

1PP07 

16139 

JI'L  31 

75 

SSN 

A76 

7AC0P 

JAN 

75 

JAN 

If 

I A1  39 

A 

1 ^00 

1 7A39 

Al'P  31 

75 

r-SN 

ft76 

7AC0P 

JAN 

75 

JAN 

If 

1 A1  39 

A 

1 500 

1 7A39 

\ 


v'Oin.r  vnn  likf  to  si'rmit  an'othff  P"fpy?-  yf? 

PLFASF  INPUT  rPFPY  CflMMANOF 
PUFRY  *?* 

IF  ASOFOATF  IF  75Pif.T0? 

SORT  ON  FCLTY 
RFPOPT  YPP 

•IFAn  1 TINF  I!  ■ atION  IS  OPDFRFP  PY  YARD* 

HEAD  S JTHF  ARFAT  '"HIP  SCFNAPIO* 

HEAD  3 SWHO  GETS  THE  MONEYS 

priNT  SUBTOTAL  PYPYPEND*  rNTYPFND,  TOTFNP  ON  FD.TY 

PRINT  TOTAL  PYPYRFNP  CNTYPFNP  TOTFNP 

SEND 

YOL'R  Pl'FPY  HAS  BEEN  ACCFPTFD 


FOR  EACH  OUFSTION,  TYPE  IN  P,  T,  OP  P. 

PIIFRY  PMFSTION  NO.  1,  HAS  IPO  HITS-T 


! 


I 


t 


f 

i 

! 

t 


Li 


YAPD  Fl'NDIMn  INFORMATION 

Information  if  oppfpfp  py  yapp 
THF  PPFAT  FHIP  FCFNAPIO 
MHO  PFTR  THF  monFY 


RFPOPT 

YPP  *P*PP 

I 

PFC  17 

YAPP 

HULL 

FTAPT 

FND 

FNP 

FNP 

rwT 

TOTAL 

PATF 

PATF 

ACTWTY 

PPIOP 

YFAP 

AI.LYP 

YFAP 

FNPF 

FNPr- 

DDF  19 

OCT  75 

AHF  7A 

75AFR 

A? 

1?7P 

1 3A1 

A3 

1 ?7R 

1 3AI 

BA 

CF  3^ 

APP  7P 

APP  7*^CPy 

53P 

71  A| 

7A71 

C 

PDF  IP 

JAN 

7A 

*** 

PFC 

iS'iPTOTAL*** 
7/1  75C0P 

71/11 

197 

7A71 

5AR0 

C 

DDF  1 1 

JUN 

7A 

MAY 

7S 

75C0P 

50 

ARIA 

C 

FFF  A 

JAN 

75 

NO'/ 

75 

75CFY 

AA0A 

695A 

C 

AS  3A 

JAN 

7A 

SFP 

7A 

75AFP 

500 

500 

C 

SSN  AP3 

MAY 

7? 

JAN 

75 

75COF 

735 

3319R 

C 

SFPN  AP9 

NOV/ 

7? 

MAP 

75 

75COP 

3?A?-a 

1 A97 

353P1 

C 

SSN  A37 

JI'L 

7A 

OCT 

77 

75AFP 

1515 

?1  15 

C 

SSN  A53 

Al'F 

75 

NOV 

7A 

75AFP 

50P0 

55R7 

C 

SSN  AAP 

JAN 

7A 

JAN 

77 

75AFP 

9A 

?31  5 

P61  1 

C 

SSN  AA9 

APR 

7A 

JI'N 

75 

75C0F 

P?6 

P6R6R 

C 

SSBN  631 

PFC 

7A 

APP 

7R 

75AFR 

/I0R 

60P 

C 

SSN  API 

OCT 

75 

NOV 

75 

75SRA 

?1  03 

P103 

C 

FF  1PI7R 

APR 

7A 

FFP 

77 

75AFP 

335 

335 

C 

FF  1P79 

MAY 

76 

MAP 

77 

75AFP 

PP3 

PR  3 

C 

PD  937 

JAN 

75 

PFC 

7S 

75CFY 

\ 

750R 

7A5R 

C 

PP  93R 

OCT 

7/1 

A"F 

75 

75CFY 

PA9 

7673 

7RP? 

C 

PPF  A5 

APP 

7/i 

MAY 

7A 

75CFY 

7079 

7PR6 

c 

FF  1PA7 

SFP 

7A 

JI'L 

75 

75CFY 

4BSP 

S?9P 

c 

FF  1HA9 

JI'N 

7A 

APP 

75 

75COF 

AA9 

6969 

c 

FF  107? 

JI'L 

75 

MAP 

76 

75AFP 

SP<C^ 

1 50 

650 

c 

FF  1075 

OCT 

75 

Al'F 

7A 

75AFP 

SI  A 

SI  A 

***FI<PT0TAL*** 


1 1 PiPF  SPPA?  1 f P70P 


404 


n 


t! 


i 


YAPP  FUNDINP  INFOPWATIOM 


INFORMATION  IS  OPPFPEP  PY  YAPP 
THF  PPFAT  SHIP  SCFNAPIO 
t'HO  PFTS  THF  MONFY 


REPORT 

YRD 

*p*mi 

PFO  1 7 

YARD 

HULL 

START 

OATF 

FNP 

PATE 

FND 

ACTVTY 

FNP 

PRIOR 

YFAP 

TNT 

YFAR 

FNPP 

TOTAL 
ALl  YR 
FNPP 

LB 

MSO 

A9? 

MAR  76 

JUN  76 

75AFPP 

6PP 

10 

69H 

♦ ♦*F(iPTOTAL*** 

6PP 

1 0 

69P 

N 

CVA 

59 

SEP 

74 

DEC 

74 

75SPA 

509? 

5475 

N 

CVA 

59 

JAN 

77 

PFC 

77 

75AFP 

1 00 

100 

N 

CVA 

6? 

MAR 

75 

JUN 

75 

75SRA 

4758 

4758 

N 

CVA 

66 

DFC 

74 

OCT 

75 

75CFY 

P8  3P9 

30970 

N 

CVA 

67 

FEB 

76 

MAY 

76 

75SPA 

1 50 

150 

N 

DDP 

3 

MAY 

75 

MAP 

76 

75CFY 

/rC^! 

830? 

8703 

N 

DPP 

A 

DFC 

75 

NOV 

76 

75AFP 

479 

479 

N 

DDP 

5 

APR 

74 

DEC 

74 

75C0P 

1 A 

465 

6979 

N 

DDP 

17 

OCT 

74 

Al'P 

75 

75CFY 

7410 

8068 

N 

DDP 

?3 

Al'P 

75 

JI'N 

76 

75AFP 

1 308 

1313 

N 

SSN 

668 

SEP 

73 

JI'L 

74 

75COP 

IP37? 

57 

184P9 

N 

SSN 

670 

JUL 

74 

MAY 

75 

7 5CFY 

1 6600 

?1?34 

N 

SSN 

675 

JI'L 

75 

JI’L 

76 

75AFP 

( 7!.7 

1 ooo 

P71  3 

N 

AD 

38 

MAY 

75 

SEP 

75 

75CFY 

907 

9?? 

N 

AOF 

3 

JI'L 

74 

EFP 

75 

75CEY 

1 C'PCT 

7364 

8364 

N 

LPH 

IP 

MAY 

75 

NOV 

76 

75AFP 

P 

POO 

?08 

N 

SSN 

678 

JAN 

76 

JAN 

77 

75AFR 

1*^ 

914 

9P9 

N 

SSN 

680 

MAP 

75 

APP 

75 

759PA 

1 390 

1 390 

N 

FF 

108  1 

JI'L 

76 

MAY 

77 

75AFP 

1 00 

100 

N 

AOP 

4 

JI'L 

76 

APP 

77 

75AEP 

87 

87 

N 

SSN 

684 

MAY 

75 

JI'N 

75 

7.5  SF  A 

I 300 

1300 

N 

DD  ' 

941 

APF 

74 

DEC 

75 

75CFY 

6938 

6938 

N 

AS 

36 

APR 

76 

OCT 

76 

75AFP 

1P5 

1P5 

♦♦•^npTPTAL*** 

93375 

1 P97?^ 

NN 

SSN 

661 

JAN 

76 

APP  77 

75AFF 

A\ 

1 539 

1 

NN 

SSN 

663 

PCT 

76 

DT  77 

754FF 

AA 

841 

♦ **<iiFTOTAL*** 

pr>np  poAs 


J97S 
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YAPP  FI'NPINA  INFOPMATION 


INFORMATION  IS  OPPFFF.P  PY  YAPP 


THF  r-PFAT  SHIP  SCFNAPIO 
V'HO  PFTS  THF  MONFY 


PFPOPT  YPD  ♦P*P!P)1 


PFC  17  1975 


YAPP 

HI 'LL 

START 

RATE 

FNP 

PATF 

FNP 

APTI'TY 

FNP 

PPIOF 

YFAP 

CNT 

YFAP 

FNPP 

TOTAL 

ALLYP 

FNPP 

NONE 

SSN  fi79 

77 

7‘^AFF 

RS7 

RS7 

***Sl'PTOTAL*»* 

P 

R7  7 

PS7 

PH 

CVA 

A? 

MAY 

74 

Al'P 

74 

7PSPA 

499 

#P99 

PH 

CP  . 

6 

NOV 

JI'L 

77 

75AFP 

PIP 

PIP 

PH 

PRP 

2 

FFP 

7S 

PFC 

75 

7RCFY 

4P5 

75P4 

79R9 

PH 

OOP 

5 

APR 

74 

FFP 

75 

75C0P 

545P 

P5P 

#71P 

PH 

POP 

le 

NOV 

7S 

OPT 

7A 

T^AFP 

43#. 

43# 

PH 

FFP 

5 

APR 

75 

NOV 

7f 

75CFY 

5P 

##54 

#7P4 

PH 

AOP 

? 

FFP 

75 

SFP 

75 

75CFY 

74 

#34P 

#4?? 

PH 

LPH 

9 

JI'L 

7*^ 

FFP 

7A 

75AFP 

OP 

?p?p 

PP5P 

PH 

LPH 

7 

SFP 

74 

APP 

75 

75CFY 

P4P 

7P#P 

P713 

PH 

LCC 

22 

JI'L 

74 

FFP 

7P 

75CFY 

P37 

#?47 

7PR4 

Report  pages  4 through  7 removed  for  this  appendix. 
Final  report  page  8 follows. 
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YAFP  FI'NDIMP  INFOPMATIOM 


INFORMATION  IF  OFPFPFP  PY  YAPP 
THF  r-PFAT  FHIP  FCFNAPIO 
V'HO  r-FTF  THF  MONFY 


PFPOPT  YPD 


PFC  17 


YAPP 

HI 'LL 

START 

PATF 

FNP  FNP 

PATF  ACTVTY 

FNP 

PPIOP 

YFAP 

CNT 

YFAP 

FNPP 

TOTAL 

ALLYP 

FNPP 

***SMPTOTAL*** 

751 

1 P39 

?591 

P 

« 

DP  7f3 
PR  P?7 

Al'P  7^ 
FFP  75 

APR  75  75CFYP 

JI'L  75  7FCFYP 

1 A? 
1 P'7 

A3i)B 

AAPI? 

A^9  1 
A7P>9 

***5iipTOTAL*'** 

pcfi 

P99P' 

PPPIPI 

9 

PP  P9 

MOV  OS 

FFP  7f  75AFPP 

♦ ♦♦5IIPTOTAL*** 

C" 

pi 

»****T0TAL**** 

.T/t/.OpC 

AP71 35 

79 A5P3 

I 97? 
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vnULP  YOtl  LIKF  TO  Sl'PMIT  PNOTHFP  PUPPY?-  YFF 


PLFASF  INPUT  PUFPY  COMMANDS 
OUFPY  *3* 

IF  FNPACTVTY  IS  7SPPPT  OF 

IF  ASOFDATF  IS  75PIF3P  ANp  FNPACTVTY  IS  7SCFY? 

RFPORT  FST 

SORT  ON  HULL  ANP  ASOFPATF 

HFAD  1 STHF  APPOPTIONMFNT  AND  THF  ACTUAL  FUNPINP  AT  YFAP  FNPf 

HFAP  ?.  «THF  C-pVaT  SHIP  SCFNAFIOS 

5FNP 

YOUR  CUFRY  HAS  PFFN  ACCFPTFP 


FOR  FACH  CUFSTION,  TYFF  IN  P,  J,  OF  P. 

PUFFY  ^ PUFSTION  NO.  1,  HAS  Ap  hiTS-T 


rt'PFFNT  YFPP  Fl'NPINF 


THF  APPOPTIONVFNT  AMP  THF  ACTI'AL  Fl'MPIMP  AT  VFAP  FMP 
THF  rPFAT  PHIP  prrMAFIO 


FFPORT  FPT 


PFP  17  I97P 


HI 'LL 

YAPP 

FMP 

START 

FN'P 

FMT  YP 

AFTMTY 

PATF 

FMPIMF 

( lDC"pi) 

AP  nR 

M 

TSCFY 

MAY 

7=; 

cpp 

7=1 

PD7 

AF  ?PP 

F 

75FFY 

Jl  'M 

7*^ 

OFT 

75 

83D 

AF  S?l 

F 

78FFY 

.11 'M 

7*^ 

OFT 

75 

8 8P 

AO  99 

3 

78FFY 

MAP 

7*^ 

8FP 

75 

AP87 

A OF  7 

N 

7 8F- Y 

Jl  L 

' /‘ 

FFP 

75 

73A  A 

AOP  ? 

PP 

78CFY 

FFP 

7S 

srp 

75 

APS  ? 

8 

78FFY 

MAY 

7*^ 

MSP 

75 

3P8  7 

APS  At" 

8 

78CITY 

crp 

7^ 

MAP 

75 

1 89B 

^PS  A 

SJ 

7 8CFY 

• Jt'M 

7S 

MOV 

75 

87? 

CP  3A 

PA 

78FFY 

APP 

7^ 

APP 

7(ft 

71  A1 

CWA  Ff 

N 

TSC^Y 

PPF 

lA 

OFT 

75 

PP3P9 

PD  937 

C 

78FFY 

JAN 

PFF 

75 

78PB 

PP  9 38 

c 

78FFY 

OFT 

1 A 

Al'F 

75 

7A73 

PP  9A1 

M 

78F8Y 

APP 

lA 

PFF 

75 

89  38 

PPF  17 

N 

78FFY 

OFT 

7 A 

Al'F 

75 

7A1  p 

PDF  ? 

PH 

78FFY 

FFP 

7=1 

PFF 

75 

789  A 

PDF  3 

N 

78FFY 

MAY 

7S 

MAP 

7^ 

9 7pf> 

PPF  A8 

r. 

78C8Y 

APP 

7 A 

MAY 

7f- 

7P70 

FF  1P38 

PH 

75FFY 

MAF 

7^ 

FFP 

75 

399(« 

FF  1PA7 

r 

78FFY 

S8p 

7 A 

JI'L 

75 

A9  88 

FF  1PP9 

PH 

78FFY 

JI'V 

7^ 

MAP 

7^ 

8Pp8 

FFF  8 

PH 

78FFY 

APP 

7^ 

NOV 

7(^ 

888A 

FFF  F 

F 

78FFY 

JAM 

75 

MOI' 

75 

88D8 

LCD  PD 

PH 

78FFY 

,II'L 

7 A 

FFP 

75 

8PA7 

LKA  117 

8 

78FFY 

• H'l. 

7 A 

FFP 

75 

8PA1 

LPP  I 

8 

75CFY 

AMF 

7 A 

AMF 

75 

7 79  7 

LPD  11 

5 

78FFY 

PFF 

7 A 

MAY 

75 

8777 

LPH  7 

PH 

75CFY 

SPP 

7 A 

APP 

75 

79  88 

LSD  3D 

5 

78F8Y 

FTP 

75 

erp 

75 

88P9 

LSP  37 

8 

78FFY 

JI'N 

75 

PFF 

75 

A897 

LST  11PD 

8 

75CFY 

JAM 

75 

.JI'L 

75 

AAI^S 

F1SO  A9P 

F 

78CFY 

OFT 

7 A 

PFF 

7^ 

?87 

PF  IDD 

8 

78CFY 

JAM 

75 

APP 

7 A 

AP7 

PF  9?  ♦ 

5 

78FFY 

APP 

7A 

.J"L 

75 

A A? 

PF  9 3 

8 

78F.FY 

JMM 

75 

OFT 

75 

8P8 

PF  98 

5 

78FFY 

JAM 

75 

APP 

75 

A98 

SSM  588 

SF 

75CPY 

,.n  '1. 

7 A 

JI'L 

7f 

PA89D 

SSN  591 

SF 

78CFY 

AMP 

7 A 

FFP 

7A 

P38A8 

SSN  FFA 

PT 

78CFY 

JI'L 

7 A 

JI'N 

75 

1 3«98 

SSN  F7D 

N 

78CFY 

Jl'I. 

7 A 

MAY 

75 

1 88PD 

SSN  F7A 

PT 

75FFY 

OFT 

7 A 

OFT 

75 

1 71  89 

SSN  F7F 

PT 

78FFY 

JAM 

75 

JAM 

75 

1PPD7 

409 


WOl'LD  YOl'  LIKF  TO  SI'PMIT  ANOTHFP  PI'FPY?-  YFF 


\ 


I 


i 

.( 

i 

I 

f 


PLFASF  INPUT  OUFRY  CONMANOP 
CUFPY  *3* 

IF  ASOFDATF  IS  TSPOP  OP  FNPACTUTY  IS  TilPpri  OF  FNPArTVTY 
75PPPT? 

PFPORT  PRY 

SORT  ON  HULL  ANP  AROFPATF 

HFAD  I SAPPnpTIONMFNT  ANP  FST  OWHL  AT  FY7S  YFAR  FNPT 
HFAP  ? TTHF  PRFAT  SHIP  SCFNAFIOf 

HFAD  3 TNAVLIS  RAISFS  PUFPTIONS  ANP  ANSVFPS  PUFSTIONS* 
f FND 

YOUP  PUFRY  HAS  PFFN  ACCFPTFP 


IS 


1 

i 


j i 


J 

I 


FOR  fach  pufstion.  typf  in  P,  T,  op  p. 

PUFRY  *3*#  PUFSTION  NO.  1.  HAS  31?  HITS-T 


FI'PPFT  TO  ACTI'/SL  PFFFOPMANrF 


APPOPTIONMENT  ANP  FP;T  OV/HL  AT  FV7S  YFAP  FNP 
TPF  PPFAT  FHIP  PCFNAPIO 
NAV/LIS  PAISF5  OMFSTIONS  ANP  A^'FVFpe  OliFFTIPN? 


PFPOPT  OPY 

♦3SPP1 

HI'LL 

FND 

PriFT 

ACTVTY 

LAPOP 
( 1PPP7 

AP  18 

7APDPT 

1 7SP 

AP  19 

7SPDPT 

199P 

AD  38 

7SPDPT 

PSA  A 

AP  38 

7SCFY 

AF  PI 

7APPPT 

1 7S3 

AF  PI 

7SCOP 

AF  P7 

TApDPT 

1 79S 

AF  P7 

7SC0P 

AF  pp 

75AFR 

AF  P8 

3APPPT 

PP9A 

AFS  ? 

7SPDPT 

PSA9 

AFS  A 

7APDPT 

?71  A 

AFS  A 

75COP 

AP  PSP 

7SCFY 

AP  5Pt 

7SPPPT 

1 79 

AP  5?1 

7SCFY 

APF  3 

7SAFF 

AO  ! ^7 

7APPPT 

3A8  3 

AO  I A7 

7SC0P 

AO  19 

7SAFP 

AO  98 

7APDPT 

APA3 

AO  98 

7SCOP 

AO  99 

7SPDPT 

Sp|9 

AO  99 

7SCFY 

AOF  3 

7SPDPT 

AP9S 

A OF  3 

7SPPY 

AOF 

7SPPPT 

SSI  P 

AOF  A 

75AFF 

AOP  SP 

7APDPT 

1 AAP 

AOP  P 

75PPrT 

SAP9 

AOP  P 

7SrPY 

AOP  A 

7SAFP 

APS  P 

7SCFY 

AP  S 

7SAFP 

APS  AP 

OSPPFT 

IP18 

APS  AP 

7SFFY 

APS  A 

7SPPFT 

9S8 

APS  A 

7SCFY 

APS  8 

7Apnr-T 

97  A 

AS  3 A 

7SAFF 

AS  3A 

7‘^APP 

ASP  13 

7APPrT 

AS? 

ASF  13 

7SCOP 

ASP  IS 

7APPrT 

7?7 

ASP  IS 

7Srop 

PFr  17 


pnr-T 

pnrT 

FST 

matl 

I 'MIT 

THOP 

0\»HL 

1 ppp) 

ro«:T 

OWHI. 

A1  A 

?1  f A 

A89 

APA 

r'l  7Pi 

9?? 

IPP 

AP7 

3a?7 

IPP 

A1  7 

PAP9 

IPP 

APP 

1 P88 

AP7 

3 A A? 

1 PP 

A3P 

IPP 

IP? 

A9P 

1 PP 

9A7 

AA8S 

IPP 

891 

^ 1 

AA1  S 

IPP 

1 P79 

A1  sp 

1 PP 

1P9A 

7S01 

83AA 

I PP 

1 1 3A 

A f/i^ 

AP  1 

1 1 PI 

AAP? 

1 PP 

3P87 

IPP 

338 

1 

1 79P 

1 PP 

3 3? 

1P9(^ 

S7P 

1 PP 

1 7? 

1 1 Af. 

1 7 

1 ASl 

) PP 

1 7 

1 AA 

38  8 A 

1 PP 

197"^ 
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Pl'PrFT  TO  ATTHAL  PFPFOPmAMTF 


APPOPTION'MFNT  AMP  FPT  OWPl.  AT  FY7P  YFAP  FMp 


THF  PPFAT  FHIP  PCFNAFIO 


NAVLl S 

PAisFS  cufstioms  amp 

AN’foVTP? 

PI'FSTIOMS 

PFPOPT  PPY 

♦ 3*f"Pil 

PFC  17  1975 

HI 'LL 

FNP 

PPPT 

pnrT 

pnri 

FST 

ACTVTY 

LAROF 

maTL 

I'WIT 

THOP 

OVHI. 

( IdP?) 

( I 

r0  5T 

OVHI 

ASP  IP 

7APPPT 

7P7 

I 7 

7AA 

ATF  1P> 

7APPP-T 

A9A 

9QP 

ATF  IPl 

7Sr.0F 

1PP9 

IPP 

ATF  IP? 

7SAFP 

ATS  1 

7SAFP 

rr  1?  0. 

7APPPT 

PI  P7 

1?7^ 

Q A.7? 

C.r.  1 7 

7 APPPT 

3 PAP 

A 1 A 

7AAP 

rr-  17 

7SC0F 

51  A9 

IPP 

cr  P7 

7APPPT 

PB7S 

cr.  ?R 

TAPPpj 

35  3.7 

^9P 

A!P«^ 

CP  OA 

7SF-PPT 

5597 

9<; 

AA9? 

C.r-  OA 

7SCFY 

7571 

IPP 

CO  A 

7SAFP 

rv  pp 

7SFPPT 

PA73P 

=i77A 

CVA  A? 

7SSPA 

rVA  S9 

7SSPA 

CVA  S9 

7SAFP 

CVA  P? 

7SSFA 

CVA  P? 

7SSFA 

CVA  PP 

7SCFY 

3PP5A 

1 PP 

CVA  P7 

7APPPT 

I 71P5 

ppiPl  «; 

CVA  P7 

7SSFA 

CVT  IP 

7 APPPT 

7959 

1 0^  A*; 

PP  “il  A 

7SPPPT 

A7PP 

A 

^ AAA 

PP  7 1 A 

7SCFYF 

APP? 

rr  7?A 

7SFPPT 

A';?? 

A 7P 

SI  7P 

pp  7P3 

7P.PPPT 

37  AP 

771 

AAPI> 

Report  abbreviated  for  this  appendix. 
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CINCLANTFLT 
NAVLIS  Scenario 

. 

Terminal  Session  and  Report  Samples 

I 

I 


i 


1 


NSROC  6700  INTERCOM  \JA.2 
DATE  12/18/75 
TIKE  13.17.11. 


w 


1 


-! 


PLEASE  LOGIN 

LOGIN. PUWEWEAVER* 1 1 80600823. SUP 


COKKAND-  ETL.500 
COMPAND-  COMRADE. SHARP 


COMRADE 


TIME! 

DATE! 


13.18.08. 

12/18/75 


SHARP  SUBSYSTEM  ENTERED 
???? 

REPDEE 


PLEASE  INPUT  REPORT  DEFINITIONS. 


ID  BASE2 
REPORT  *1* 

WIDTH  = 130 

MHEAD  $A  NAVLIS  REPORTS 


130 


COL 

HEAD 

1 = 

SHULLS 

COL 

HEAD 

2 = 

SSHIPS 

COL 

HEAD 

3 = 

SASOF /DATES 

COL 

HEAD 

4 = 

SSTART/DATES 

COL 

HEAD 

5 = 

SEND/DATES 

COL 

HEAD 

6 = 

STYPE/OVHLS 

COL 

HEAD 

7 = 

SACT/MDAYSS 

COL 

HEAD 

8 = 

SFND/ACTVTYS 

COL 

HEAD 

9 = 

SBDGT/LBR/DAYSS 

COL 

HEAD 

10 

= SBDGT/LBR/MNYS 

COL 

HEAD 

1 1 

= SBDGT/MATL/MNYS 

COL 

HEAD 

12 

= SBDGT/UNIT/COSTS 

COL 

HEAD 

13 

= SEST/THOR/OVHLS 

COL 

HEAD 

1 4 

= SPCNT/OVHLS 

COL 

HEAD 

16 

= SSTD/OVHL/DURS 

COL 

HEAD 

17 

= SSTD/OVHL/INTVLS 

PRINT  HULL.  SHIP.  ASOFDATE.  STARTDATE.  ENDATE.  TYPEOVHL. 


ACTLDAYS.  FNDACTVTY.  BDGTLDAYS. 
BDGTUCOST.  ESTOVHL.  PERCNTOVHL. 
SEND 


BDGTLMNY.  BDGTMMNY. 
DURATN.  INTRVL 
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REPORT  DEFINITION  ERROR  SUPNARY 


,1 

■i 


ID 


BASE2 


EPORT  - *!♦ 

NO  ERRORS  FOUND  - REPORT  DEFINITION  ACCEPTED 
??  ? ? 

EX  ID=  CADC  PFN=DATADEFFILE 

EX  CY=  001  00001569  PRUS  $0003.92  /DAY 

lOUERY 


YOU  HAVE  SELECTED  THE  INTERACTIVE  QUERY  OPTION. 

WOULD  YOU  LIKE  AN  EXPLANATION  OF  THE  SYSTEF7-NO 

' i 
1 

SELECT  ONE  OF  THE  FOLLOWING  DATA  BASES  j 

18  LOGISTICS  DOCUMENT  DATA  BANK  j 

31  YURSO  DATA  BANK  j 

32  PKRS-BASE-2  \ 

??  32  j 

PLEASE  INPUT  QUERY  COPLANDS  i 


QUERY 

IF  HISTDATA  IS  OVHL  OR 

PREFIX  FNDACTVTY  IS  BE  TO  13/16  OR 

SCDACTVTY  IS  PROJ? 

REPORT  *1* 

SORT  ON  HULL  AND  ASOFDATE 

HEAD  1 SDISPLAY  OF  DISTRIBUTED  FILE  INFORMATIONS 
HEAD  S SSHIP  - SCHEDULING 

HEAD  2 SSHIP  SCHEDULING  - ATLANTIC  FLEETS 

HEAD  3 SBOW  WAVE  PROBLEM  ANALYSISS 

SEND 

YOUR  QUERY  HAS  BEEN  ACCEPTED 


FOR  EACH  QUESTION*  TYPE  IN  D»  T*  OR  B. 

QUERY  ♦!*»  QUESTION  NO.  1.  HAS  37A9  HITS-B 
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CINCLANTFLT 


Ship  Identification  Scenario 


Terminal  Session  and  Report  Samples 


Attachment  #7 


420 


1 


1 


NSRDC  6700  INTERCOM  V4.2 
DATE  12/23/75 
TIME  15.59.12. 


PLEASE  LOGIN 

LOGIN>PUUEUEAVER> 1180600823rSUP 


COMMAND-  ETLi500 


COMMAND-  COMRADEiSHARP 


COMRADE  TIME:  15.59.49. 

date:  12/23/75 

SHARP  SUBSYSTEM  ENTERED 
????  IQUERY 


YOU  HAVE  SELECTED  THE  INTERACTIVE  QUERY  OPTION. 
WOULD  YOU  LIKE  AN  EXPLANATION  OF  THE  SYSTEM9-N0 


SELECT  ONE  OF  THE  FOLLOWING  DATA  BASES 
18  LOGISTICS  DOCUMENT  DATA  BANK 

31  YURSO  DATA  BANK 

32  MKRS-BASE-2 
??  32 


PLEASE  INPUT  QUERY  COMMANDS 
QUERY  DO 


IF 

SHIPID 

IS 

OILER? 

IF 

SHIPID 

IS 

CARRIER? 

IF 

SHIP  ID 

IS 

GARBAGE? 

IF 

SHIPID 

IS 

MINESWEEPER? 

IF 

SHIPID 

IS 

GASOLINE? 

IF 

SHIPID 

IS 

SSN? 

IF 

SHIP  ID 

IS 

PATROL? 

IF 

SHIPID 

IS 

TENDER? 

IF  PARTIAL  SHIPS  IS  (91F0X? 


IF  PREFIX  SHIPS  IS  SSN  673? 
«END 

YOUR  QUERY  HAS  BEEN  ACCEPTED 
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FOR  EACH  QUESTION.  TYPE  IN  D>  T.  OR  B. 


QUERY 

DO 

QUESTION 

NO. 

1 1 

HAS 

2 

HITS-T 

QUERY 

DO 

QUESTION 

NO. 

2. 

HAS 

6 

HITS-T 

QUERY 

DO 

QUESTION 

NO. 

3 r 

HAS 

2 

HITS-T 

QUERY 

DO 

QUESTION 

NO. 

4. 

HAS 

15 

HITS-T 

QUERY 

DO 

QUESTION 

NO. 

5. 

HAS 

3 

HITS-T 

These  reports 

QUERY 

DO 

QUESTION 

NO. 

6 f 

HAS 

2 

HITS-T 

, removed  for 

this  appendix 

QUERY 

DO 

QUESTION 

NO. 

7. 

HAS 

13 

HITS-T 

QUERY 

DO 

QUESTION 

NO. 

8. 

HAS 

9 

HITS-T 

QUERY 

DO 

QUESTION 

NO. 

9. 

HAS 

1 

HITS-T 

QUERY 

DO 

QUESTION 

NO. 

10. 

HAS 

1 

HITS-T  , 

REPORT  DFT  DO  001 


DEC  23  1975 


PROC/DATE:  751015 
RCDIDi  200003034 
SHIPID*  AO 

OILER 

SHIPS:  AO  144  HISSISSINEWA  05904 

AO  147  TRUCKEE  05907 

AO  98  CALOOSAHATCHEE  04848 


PROC/DATEi  751015 
RCDIDt  200003037 
SHIPID:  AOR 

REPLENISHMENT 

OILER 

ships:  AOR  2 MILWAUKEE  05850 

AOR  4 SAVANNAH  20123 

AOR  6 KALAMAZOO  20125 


k 


AIRCRAFT 

CARRIER 


SHIPS:  CVA 

42 

ROOSEVELT 

03342 

CVA 

59 

FORRESTAL 

03359 

CVA 

60 

SARATOGA 

03360 

CVA 

62 

INDEPENDENCE 

03362 

CVA 

66 

AMERICA 

03366 

CVA 

67 

KENNEDY 

03367 

PROC/DATE:  751015 
RCDID:  200003083 
SHIPID:  CVAN 

ATTACK 

AIRCRAFT 

CARRIER 

NUCLEAR 

SHIPS:  CVAN  NIMITZ  03368 


PROC/DATE:  751015 
RCDID:  200003084 
SHIPID:  CVE 

AIRCRAFT 

CARRIER 

ESCORT 

ships:  none 


PROC/DATE:  751015 
RCDID:  200003085 
SHIPID:  CVS 

AIRCRAFT 

CARRIER 

ASM 

SHIPS:  CVS  16  LEXINGTON  03318 
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REPORT  DFT  DO  002 


DEC  23  1975 


f 


: I 


PROC/DATEJ  751015 
RCDIDi  200003086 
SHIPID:  CVT 

AIRCRAFT 

CARRIER 

TRAINING 

ships:  NONE  ’ 

I 


I 

i 

I 

j 

1 

I 

I 


! 

i 

i 

j 


i 


>I 
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MOULD  YOU  LIKE  TO  SUBMIT  ANOTHER  QUERY?-  YES 


PLEASE  INPUT  QUERY  COMMANDS 
QUERY  1.1 

IF  PARTIAL  SHIPS  IS  <9)SUNBIRD? 
PRINT  ALL 

HEAD  1 *THE  SHIP  IS  THE  «BIRD* 
HEAD  2 *SHARP  IS  TO  THE  ** 

HEAD  3 «THE  POINT  IS  SHARP* 

*END 

YOUR  QUERY  HAS  BEEN  ACCEPTED 


FOR  EACH  OUESTIONf  TYPE  IN  D»  Tf  OR  B. 
QUERY  1 I QUESTION  NO.  li  HAS 


1 HITS-T 
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PROC/DATE:  751015 
RCDID:  Z00003058 
SHIPIDt  ASR 

SUBMARINE 

RESCUE 

SHIP 


SHIPS*  ASR 

13 

KITTIHAKE 

04712 

ASR 

14 

PETREL 

04713 

ASR 

15 

SUNBIRD 

04714 

ASR 

16 

TRINCA 

04715 

ASR 

22 

ORTOLAN 

20144 

REPORT  DFT  1 001 


THE  SHIP  IS  THE  *BIRD 
SHARP  IS  TO  THE  * 
THE  POINT  IS  SHARP 


DEC  23  1975 
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CINCLANTFLT 


Scenario  II 

Terminal  Sessions  and  Sample  Reports 


Attachment  #8 


19/7=. 75 
TIME  14.41.01. 

PLEASE  LOGIN 

LOG  IN  t PUWEWEAVER  < 1 18060(332  3 f SUP 

WAITING  FOR  INPUT 
I ODER T 


PLEASE  ANSWER  YES  OR  NO-  NO 


????  lOUERY 


you  HAVE  SELECTED  THE  INTERACTIVE  QUERY  OPTION. 
WOULD  YOU  LIKE  AN  EXPLANATION  OF  THE  SYSTEM?-NO 

SELECT  ONE  OF  THE  FOLLOWING  DATA  BASES 
18  LOGISTICS  DOCUMENT  DATA  BANK 

31  YURSO  DATA  BANK 

32  MKRS-BASE-2 
??  32 


PLEASE  INPUT  QUERY  COMMANDS 


QUERY  WES 

IF  A30FDATE  IS  7'50630 
HULL  IS  DOG? 

IF  ASOFDATE  IS  750331 

hul;l 

HULL  IS  DDG? 

*END 


AND  PREFIX  ENDATE  IS  LE 
AND  PREFIX  ENDATE  IS  LE 


TO  7506  AND  PREFIX 
TO  750331  AND  PREFIX 


your  query  HAS  BEEN  ACCEPTED 


FOR  EACH  QUESTIONf  TYPE  IN  Di  T»  OR  B. 


QUERY 

WESf 

QUESTION 

NO. 

1 > HAS 

5 HITS-T 

QUERY 

WESf 

QUESTION 

NO. 

2t  HAS 

1 HITS-T 
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REPORT  DPT  UES001 


DEC  29  1975 


ASOFDATE:  750630 
CDR:  sharp 
CNTPLNTOT:  5680 

CNTYRFND:  197 

CNTYRPLN:  197 

ENDATE:  7412 
ESTCNTYRQ:  197 

ESTOVHL:  5630 

FCLTY:  C 

FNDACTVTY:  75C0R 
hull:  DDG  13 
navy:  CINCLANTFLT 
PERCNTOVH:  100 

PROC/DATE:  751029 
PYRYRFND:  5483 

RCDID:  046435227 
SHIP:  SEMMES 
STARTDATE:  7401 
TOTFND:  5680 

TYCOM:  2 
UIC:  4648 


ASOFDATE:  750630 
CDR:  SHf>RP 
CNTPLNTOT:  6979 

CNTYRFND:  465 

CNTYRPLN:  465 

ENDATE:  7412 
ESTCNTYRQ:  465 

ESTOVHL:  6979 

FCLTY:  N 

FNDACTVTY:  75C0R 
hull:  DDG  5 
navy:  CINCLANTFLT 
PERCNTOVH;  100 
PROC/DATE:  751029 
PYRYRFND:  6514 

RCDID:  046715224 
SHIP:  RICKETTS 
STARTDATE:  7404 
TOTFND:  6979 

TYCOM:  2 
UIC:  4671 
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REPORT  DPT  WES001 


flSOFDATE:  750630 
CDR:  SHARP 
CNTPLNTOT:  6710 

CNTYRFND:  260 

CNTYRPLN:  260 

ENDATE:  7502 
ESTCNTYRQ:  260 

ESTOVHL:  6710 

FCLTY:  PH 
FNDACTVTY:  75C0R 
HULL:  DOG  6 
NAVY:  CINCLANTFLT 
PERCNTOVH:  100 

PROC/DATE:  751029 
PYRYRFND:  6450 

RCDID:  046725225 
SHIP:  BARNEY 
STARTDATE:  7404 
TOTFND:  6710 

TYCOH:  2 
UIC:  4672 


ASOFDATE:  750630 
CDR:  SHARP 
CNTPLNTOT:  6316 

CNTYRFND:  50 

CNTYRPLN:  50 

ENDATE:  7505 
ESTCNTYRQ:  50 

ESTOVHL:  6316 

FCLTY:  C 

FNDACTVTY:  75C0R 
HULL:  DDG  11 
NAVY:  CINCLANTFLT 
PERCNTOVH:  100 

PROC/DATE:  751029 
PYRYRFND:  6766 

RCDID:  046775226 
SHIP:  SELLEf^S 
STARTDATE:  7406 
TOTFND:  6316 

TYCOM:  2 
UIC:  4677 


REPORT  DFT  WES001 


DEC  29  1975 


ASOFDATE: 

750630 

CDR:  SHARP 

CNTPLNTOT: 

9307 

CNTYRFND: 

325 

CNTYRPLN: 

325 

ENDATE:  7501 

ESTCNTYRQ: 

325 

ESTOVHL! 

9307 

FCLTY:  PH 

fndactvty; 

75C0R 

hull:  DDG 

37 

navy:  CINCLANTFLT 

PERCNTOVH: 

100 

PROC/DATE; 

751029 

PYRYRFND: 

3932 

RCDID:  522315222 

SHIP:  FARRAGUT 

STARTDATE: 

7311 

TOTFND:  9307 

TYCOM:  2 

UIC:  52231 

! 


REPORT  DPT  WES002 


DEC  29  1975 


flSOFDATE:  750831 
CDR:  SHARP 
CNTPLNTOT:  8088 

CNTYRFND;  19 

CNTYRPLN:  20 

ENDATE:  7508 
ESTCNTYRQ:  20 

ESTOVHL:  3088 

FCLTY:  N 

FNDACTVTY:  76COR 
HULL!  DDC  17 
NAVY:  CINCLANTFLT 
PERCNTOVH:  100 

PROC/DATE:  751209 
PYRYRFNO:  8068 

RCDID:  046335587 
SHIP:  CONYNGHAIi 
STARTDATE:  7510 
TOTFND!  8037 
TYCOM!  2 
[C!  4683 


433 


tiimt 


WOULD  rou  LIKE  TO  SUBMIT  ANOTHER  OUERY?-  NO 


REPDEF 


PLEASE  INPUT  REPORT  DEFINITIONS. 

ID  DA3E2 
REPORT  WES 
WIDTH  = 130 

MHEAD  «MONTHLY  FUNDING  PROFILE* 


130 

COL 

HEAD 

1 

COL 

HEAD 

2 

COL 

HEAD 

3 

COL 

HEAD 

4 

COL 

HEAD 

COL 

HEAD 

6 

COL 

HEAD 

7 

COL 

HEAD 

9 

COL 

HEAD 

9 

COL 

HEAD 

10 

COL 

HEAD 

11 

COL 

HEAD 

12 

COL 

HEAD 

IQ 

COL 

HEAD 

13 

COL 

HEAD 

14 

PRINT  HULL. 
CNTYRPLN.  C 


»HULL* 

*A30F/DATE» 

*'3TART/DATE» 

*END/DATE* 

*FCLTY* 

»PYRYR/FND* 

4CH0RD* 

*CNTYR/PLAN» 

*CNT/PLAN/TOTAL$ 

= *TOTFND/ALLYR/TODTE» 

= *CNT/YEAR/FNDG» 

= *EST/CNTYR/Ri3MT* 

= -lEST/OVHL* 

= iPERCNT/OUHL* 

ASOFDATEf  STARTDATE.  ENDATE 
NTPLNTOT.  TOTFND.  CNTYRFND. 


. FCLTY.  PYRYRFND.  CHORD. 
ESTCNTYRQT.  E3TOVHL . 


PERCNTOVHL 

«ENO 


REPORT  DEFINITION  ERROR  SUMMARY 
ID  - BASE2 


REPORT  - WES 

NO  ERRORS  FOUND  - REPORT  DEFINITION  ACCEPTED 
QUERY 

EX  ID*  CADC  PFN=DATADEFFILE 

EX  CY*  001  00001617  PRUS  *0004.04  /DAY 


YOU  HAVE  SELECTED  THE  SHARP  QUERY  OPTION. 

WOULD  YOU  LIKE  AN  EXPLANATION  OF  THE  SYSTEM7-N0 


DO  YOU  WISH  TO  SUBMIT  A QUERY  RUN7-NO 
??’?  IQUERY 
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YOU  HAVE  SELECTED  THE  INTERACTIVE  QUERY  OPTION. 
WOULD  YOU  LIKE  AN  EXPLANATION  OF  THE  SYSTEM7-N0 


SELECT  ONE  OF  THE  FOLLOWING  DATA  BASES 
18  LOGISTICS  DOCUMENT  DATA  BANK 

31  YURSO  DATA  BANK 

32  MKRS-BASE-2 
??  32 


PLEASE  INPUT  QUERY  COMMANDS 
QUERY  UIE3 

IF  SUFFIX  FNDACTVTY  IS  NE  TO  BDGT  AND 
ASOFDATE  IS  BE  TO  74(3731/75(3831  AND 
HISTDATE  IS  NE  TO  OVHL  AND 
SCDACTVTY  IS  NE  TO  PROJ  AND 

FATAL  ERROR--SEARCH  VALUE  TOO  LARGE  --QUERY  WES.  QUESTION  (301 

ABOVE  QUESTION  WAS  NOT  PROCESSED.  PLEASE  EXAMINE  FOR  SYNTAX  ERROR 
AND  CONTENT.  RE-ENTER  IF  POSSIBLE 

IF  SUFFIX  FNDACTVTY  IS  NE  TO  BDGT  AND 
ASOFDATE  IS  BE  TO  74(3731/750331  AND 
HISTDATA  IS  NE  TO  OVHL  AND 
SCDACTVTY  IS  NE  TO  PROJ  AND 
PREFIX  HULL  IS  DDG  AND 

SUFFIX  HULL  IS  13  OR  5 OR  6 OR  11  OR  37  OR  17 
SUFFIX  HULL  IS  13  OR  5 OR  6 OR  11  OR  37  OR  17? 

REPORT  WES 

SORT  ON  HULL  AND  ASOFDATE 

HEAD  1 OCLASS  DDG  SHIPS  - ATLANTIC  FLEET* 

*END 

YOUR  QUERY  HAS  BEEN  ACCEPTED 
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I 


NO  HITS  j 

ALTHOUGH  INDIVIDUAL  SEARCH  CRITERIA  WERE  METr  NO  RECORD  ON  THE  | 

DATA  BASE  SATISFIED  THE  USER'S  COMBINATION  OF  REQUIREMENTS.  1 

WOULD  YOU  LIKE  TO  SUBMIT  ANOTHER  QUERY?-  YES  j 

i 

PLEASE  INPUT  QUERY  COMMANDS  ! 

QUERY  WES 

IF  SUFFIX  FNDACTVTY  IS  COR  AND  PREFIX  HULL  IS  DDG  AND  SUFFIX  HULL  IS  J 

13  OR  5 OR  6 OR  11  OR  37  OR  17? 

REPORT  WES  ] 

SORT  ON  HULL  AND  A30FDATE 

HEAD  1 «CLASS  DDG  SHIPS  - ATLANTIC  FLEET* 

*END 

YOUR  QUERY  HAS  BEEN  ACCEPTED 


FOR  EACH  OUESTIONi  TYPE  IN  Di  T,  OR  B. 

QUERY  WESf  QUESTION  NO.  If  HAS  55  HITS-B 


HONTHtr  FUNDING  PROFILE 
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WOULD  YOU  LIKE  TO  SUBHIT  ANOTHER  QUERY?-  YES 

PLEASE  INPUT  QUERY  COHHANDS 
QUERY  WES 

IF  ASQFDATE  IS  BE  TO  74073 1/73Q831  AND 
PPFFIH  JJULL.-IS-  BBC  AMD 

SUFFIX  HULL  IS  18  OR  3 OR  6 OR  11  OR  37  OR  17  AND 

SUFFIX  FNDACTVTY  IS  COR  OF  CFY  OR  SRA  OR  AFR  OR  CORR  OR  CFYR  OR 

AFRR? 

REPORT  WES 

SORT  ON  HULL  AND  ASOFDATE 

HEAD  1 4CLASS  DDG  SHIPS  - ATLANTIC  FLEET* 

«ENO 

YOUR  QUERY  HAS  BEEN  ACCEPTED 


T 


FOR  EACH  QUESTIONf  TYPE  IN  D»  T.  OR  B. 

QUERY  UESi  QUESTION  NO.  If  HAS 
XA 


81  HITS-T 


USER  ABORT 


SIS  ERROR  RECOVERY 
FOLLOWING  FILES  TO  BE  CLOSED  BY  SIS 
RECOVERY - 

REPDEF3 

YES 


PLEASE  INPUT  QUERY  COMMANDS 


MONTHLY  FUNDING  PRO 
CLASS  DDC  SHIPS  - ATLAN 


REPORT 

WES 

WES001 

HULL 

ASOF 

START 

END 

FCLTY 

PYRYR 

DATE 

DATE 

DATE 

FND 

DOC  11 

SEP  30 

74 

JUN  74 

JUL  75 

C 

6534 

DOG  11 
DDC 

OCT  31 

74 

JUN  74 

JUL  75 

C 

6534 

DDC  11 

NOV  30 

74 

JUN  74 

JUL  75 

C 

6534 

DDC  11 

n 

DEC  y.A 

USER  ABORT 

QUERY 

RUN 

ABORTED 

IN 

ROUTINE  REPCN 

WOULD 

YOU 

LIKE  TO 

SUBMIT  ANOTHER 

QUERY?- 

PLEASE 

ANSWER  YES 

OR 

NO- 

I ) 
; ( 


QUERY  WES 

IF  ASOFDATE  IS  BE  TO  7A0731/750331  AND 
PREFIX  HULL  IS  DDC  AND 

SUFFIX  HULL  IS  13  OR  5 OR  -!.  OR  11  OR  37  OR  17  AND 

SUFFIX  FNDACTVTY  IS  COR  OR  CFY  OR  3RA  OR  AFR  OR  CORR  OR  CFYR  OR 

AFRR? 

REPORT  WES 

SORT  ON  HULL  AND  ASOFDATE 

HEAD  1 *CLA33  DDC  SHIPS  - ATLANTIC  FLEET* 

*END 

YOUR  QUERY  HAS  BEEN  ACCEPTED 
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MONTHLY  FUNDING  PtOFILE 
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OOG  6 JUN  7?  »PR  74  FCB  75  PH  6450  ?60  6710  6710  260  261  6710  100 


WOULD  YOU  LIKE  TO  SUBHIT  ANOTHER  QUERY?-  NO 


????  REPDEF 


PLEASE  INPUT  REPORT  DEFINITIONS. 


ID  BA3E2 
REPORT  *1 

MHEAU  !»AVEHAGE  COST  OF  OVERHAUL* 

COL  HEAD  1 = *HULL* 

= *YARD* 

= ^FND/ACTVTY* 

= *BDGT/LABOfJ/DAYS* 

= *BDGT/LABOR/liONEY* 

= *BDGT/MATL/liONEY* 

PRINT"H.lL,\-CLTYyFm5^  BDGTLDAYS,  BDGTLHNY . BDGTMHNY, 

BUGTUCOST 
♦END 


COL  HEAD 
COL  HEAD 
COL  HEAD 
COL  HEAD 
COL  HEAD 
COL  HEAD 


1 


I 

I 

1 
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????  IQUCHY 


r 


YOU  HAVE  SELECTED  THE  INTERACTIVE  QUERY  OPTION. 
WOULD  YOU  LIKE  AN  EXPLANATION  OF  THE  SYSTEM?-NO 


SELECT  ONE  OF  THE  FOLLOWING  DATA  BASES 
18  LOGISTICS  DOCUMENT  DATA  BANK 

31  YURSO  DATA  BANK 

32  MKRS-BASE-2 
??  32 

PLEASE  INPUT  QUERY  COMMANDS 
QUERY  *X  ! 

IF  PREFIX  HULL  IS  LST  AND 
FNDACTVTY  IS  74BDCT  AND 
PREFIX  FCLTY  IS  BE  TO  (3/9? 

REPORT  *1 

HEAD  1 «LST  APPORTIONMENT  FOR  FISCAL  74» 

HEAD  2 ^NUMERIC  YARDS  ONLY?* 

IF  PREFIX  HULL  IS  LST  AND 
FNDACTVTY  IS  74BDGT  AND 

! PREFIX  FCLTY  IS  BE  TO  A/Z? 

REPORT  *1 
SORT  ON  HULL 

HEAD  1 *L3T  APPORTIONMENT  FOR  FISCAL  74* 

HEAD  2 *A(.PHABETIC  YARDS  ONLY* 

IF  f’REFIX  HULL  IS  LST  AND 

I FNDACTVTY  IS  74BDGT  AND 

PREFIX  FCLTY  IS  BE  TO  (3/9? 

REPORT  *1 

HEAD  1 *LST  APPORETIONMENT  FOR  FISCAL  74* 

HEAD  2 *NUMERIC  YARDS  ONLY* 

PRINT  AVERAGE  BDGTLDAYSr  BDGTLMNY , BDGTMMNYf  BDGTUCOST 
IF  PREFIX  HULL  IS  LST  AND 

, FNDACTVTY  IS  74BDGT  AND 

PREFIX  FCLTY  IS  BE  TO  A/Z? 

REPORT  *1 

HEAD  1 *LST  APPORTIONMENT  FOR  FISCAL  74* 

’ HEAD  2 *ALPHABETIC  YARDS  ONLY* 

SORT  ON  HUl.L 

; PRINT  AVERAGE  BDGTLDAYSi  BDGTLMNY t BDGTMMNY.  BDGTUCOST 

i 

i 

j 

( 

/ 


f 


IF  PREFIX  HULL  13  L3T  AND 
FNUACTVTY  IS  73BUGT  AND 
PREFIX  FCLTY  13  HE  TO  0/3? 

REPORT  *1 

HEAD  1 «L3T  APPORTIONMENT  FOR  FISCAL  75« 

NUMERIC  YARDS  0NLY4 

HEAD  2 !tNUMERIC  YARDS  ONLY 4 

PRINT  AVERAGE  BDGTLDAYSt  BDGTLMNYf  BDGTMMNYf  BDGTUCOST 
IF 

SORT  ON  HULL 

IF  PREFIX  HULL  IS  LST  AND 
FNDACTVTY  IS  7‘5BDGT  AND 
PREFIX  FCLTY  IS  BE  TO  A/Z? 

REPORT  «1 
SORT  ON  HULL 

HEAD  I 4L3T  APPORT lONMNENT  FOR  FISCAL  75* 

HEAD  2 4ALPHABERTIC  YARDS  ONLY* 

PRINT  AVEFIAGE  DBDGTLDAYSf  BDGTLMNYf  BDGTMMNYf  BDGTUCOST 
*END 

YOUR  QUERY  HAS  BEEN  ACCEPTED 


FOR  EACH  QUESTIONf  TYPE  IN  Df  Tf  OR  B. 


QUERY 

#X  ! f 

QUESTION 

NO. 

1 f HAS 

1 

HITS-D 

QUERY 

»X  ' f 

QUESTION 

NO. 

2f  HAS 

0 

HITS 

QUERY 

*X  ! f 

QUESTION 

NO. 

3f  HAS 

1 

HITS-T 

QUERY 

*X  ! f 

QUESTION 

NO. 

4f  HAS 

0 

HITS 

QUERY 

*X!  f 

QUESTION 

NO. 

5f  HAS 

1 

HITS-T 

QUERY 

*X  ! f 

QUESTION 

NO. 

Af  HAS 

0 

HITS 
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AVERAGE  COST  OF  OVERHAUL 
LST  APPORETIONMENT  FOR  FISCAL  74 
NUMERIC  YARDS  ONLY 

REPORT  *1  »X!003 


HULL 

YARD 

FND 

ACTVTY 

BDGT 

LABOR 

DAYS 

BDGT 

LABOR 

MONEY 

BDGT 

MATL 

MONEY 

BDGT 

UNIT 

COST 

LST  1179 

5 

74BDGT 

2895 

737 

3632 

♦♦♦•average*** 

* 2395  737  3632 
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ISRDC  6700  INTERCOM  V4.2 
DATE  12/29/75 
TIME  16.26.21. 

PLEASE  LOGIN 

LOGIN.PlJWEUEAVERf  1130600323  F SUP 
WAITING  FOR  INPUTYES 


PLEASE  INPUT  QUERY  COMMANDS 
QUERY  *X ! 

IF  PREFIX  HULL  IS  L3T  AND 
FNDACTVTY  IS  ■'ABDGT  AND 
PREFIX  FCLTY  IS  BE  TO  0/9? 

REPORT  *1 
SORT  ON  HULL 

PRINT  AVERAGE  BDGTLDAYSf  BDGTLMNYf  BDGTMMNYf  BDGTUC03T 
HEAD  1 «LI3T  APPORTIONMENT  FOR  FISCAL  74$ 

HEAD  2 ^NUMERIC  YARDS  ONLY$ 

IF  PREFIX  HULL  IS  LST  AND 
FNDACTVTY  IS  74BDGT  AND 
PREFIX  FCLTY  IS  BE  TO  A/Z? 

REPORT  *1 
SORT  ON  HULL 

PRINT  AVERAGE  BDGTLDAYSf  BDGTLMNYf  BDGTMMNYf  BDGTUCOST 
HEAD  1 $L3T  APPORTIONMENT  FOR  FISCAL  74* 

HEAD  2 *ALPHABETIC  YARDS  ONLY** 

IF  PREFIX  HUfLL  is  LST  AND 
FNDACTVTY  IS  75BDGT  AND 
PREFIX  FCLTY  IS  BE  TO  0/9  ? 

REPORT  *1 
SORT  ON  HULL 

PRINT  AVERAGE  BDGTLDAYSf  BDGTLMNYf  BDGTMMNYf  BDGTUCOST 
HEAD  1 *LST  APPORTIONMENT  - FISCAL  75* 

HEAD  2 *NUMERIC  YARDS  ONLY* 

IF  PREFIX  HULL  IS  LST  AND 
FNDACTVTY  IS  /SBDGT  AND 
PREFIX  FCLTY  IS  BE  TO  A/2^ 

1 REPORT  *1 

< SORT  ON  HULl. 

PRINT  AVERAGE  BDGTLDAYSf  BDGTLMNYf  BDGTMMNYf  BDGTUCOSAT 

: PRINT  AVERAGE  BDGTLDAYSf  BDGTLMNYf  BDGTMMNYf  BDGTUCOST 

HEAD  1 *LST  apportionment  FOR  FISCAL  75* 

: HEAD  2 *APLHABETIC  YARDS  ONLY* 

• *END 

' YOUR  QUERY  HAS  BEEN  ACCEPTED 


FOR  EACH  QUESTIONf  TYPE  IN  Df  Tf  OR  B. 


QUERY 

*X  1 F 

QUESTION 

NO. 

1 F 

HAS 

1 

HITS-T 

QUERY 

• X 1 • 

QUESTION 

NO. 

2f 

HAS 

0 

HITS 

QUERY 

»X  ! t 

QUESTION 

NO. 

3f 

HAS 

0 

HITS 

I 

1 


J 
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AVERAGE  COST  OF  OVERHAUL 
LIST  APPORTIONMENT  FOR  FISCAL  74 
NUMERIC  YARDS  ONLY 


REPORT  *1 

*X 1001 

DEC 

29  1975 

HULL 

YARD 

FND 

BDGT 

BDGT 

BDGT 

BDGT 

ACTVTY 

LABOR 

LABOR 

MATL 

UNIT 

DAYS 

MONEY 

MONEY 

COST 

LST  1179 

5 

74BDGT 

**»*average**« 

2895 

737 

3632 

2395 

737 

3632 
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WOULD  YOU  LIKE  TO  SUBMIT  ANOTHER  QUERY?-  YES 


PLEASE  INPUT  QUERY  COMMANDS 
QUERY  -»X1 

IF  PREFIX  HULL  IS  DE  OR  FF  AND 
FNDACTVTY  IS  74BUGT  AND 
PREFIX  FCLTY  IS  HE  TO  (3/9? 

REPORT  *1 
SORT  ON  HULL 

PRINT  AVERAGE  BDGTLDAYSf  HDGTLMNYt  BDGTMMNYf  BDGTUCOST 
HEAD  1 !»DE  AND  FF  APPORTIONMENT  FOR  FISCAL  7Ai 
HEAD  2 !*NUMERIC  YARDS  ONLY* 

IF  PREFIX  HULL  IS  UE  OR  FF  AND 


FNDACTVTY 


75BDGT  AND 


PREFIX  FCLTY  IS  BE  TO  A/Z? 
REPORT  *1 
SORT  ON  HULL 

b6bbbbbbbbb 

PLEASE  LOGIN 

LOGIN.PUWEWEAVERf  1 13i3600323  f SUP 

WAITING  FOR  INPUT 
YES 


»«fWE  WILL  BE  GOING  DOWN  ABOUT  1900 
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NSRDC  6700  INTERCOM  V4 . 2 
DATE  12/29275 
TIME  16.56.38. 

PLEASE  LOGIN 

LOGINrPlJWEWEAVERf  1 1306(30823  fSUP 
WAITING  FOR  INPUTV.A 


USER  ABORT 

QUERY  RUN  ABORTED  IN  ROUTINE  LT 

WOULD  YOU  LIKE  TO  SUBMIT  ANOTHER  QUERY?- 
SIS  ERROR  RECOVERY 
FOLLOWING  FILES  TO  BE  CLOSED  BY  SIS 
RECOVERY- 

REPDEF3 

YES 


PLEASE  INPUT  QUERY  COMMANDS 
QUERY  -itXl 

IF  PREFIX  HULL  IS  DE  OR  FF  AND 
FNDACTVTY  IS  74HDGT  AND 
PREFIX  FCLTY  IS  BE  TO  0/9? 

REPORT  *1 
SORT  ON  HULL 

PRINT  AVERAGE  BDGTLDAYSr  BDGTLMNY r BDGTMMNYi  BDGTUCOST 
HEAD  1 (*DE  AND  FF  APPORTIONMENT  FOR  FISCAL  75» 

HEAD  2 !»NUMERIC  YARDS  ONLY$ 

IF  PREFIX  HULL  IS  DE  OR  FF  AND 
FNDACTVTY  IS  75BDGT  AND 
PREFIX  FCLTY  IS  BE  TO  A/2? 

REPORT 
SORT  0 N 
SORT  ON  HULL 

PRINT  AVERAGE  BDGTLDAY3.  BDGTLMNY f BDGTMMNY f BDGTUCOST 
HEAD  1 <DE  AND  FF  APPORTIONMENT  FOR  FISCAL  75* 

HEAD  2 'lALPHABETIC  YARDS  ONLY* 

*END 

YOUR  QUERY  HAS  BEEN  ACCEPTED 


FOR  EACH  QUESTIONf  TYPE  IN  Dr  Tr  OR  B. 


QUERY  *Xlr  QUESTION  NO. 
QUERY  *Xlr  QUESTION  NO. 
T 


1 t HAS 
2r  HAS 


0 HITS 
6 HITS- 
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f 


I 

( 
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AVERAGE  COST  OF  OVERHAUL 
DE  AND  FF  APPORTIONMENT  FOR  FISCAL  75 


ALPHABETIC  YARDS  ONLY 


REPORT  »1 

*X1002 

DEC 

29  1975 

HULL 

YARD 

FND 

BDGT 

BDGT 

BDGT 

BDGT 

ACTVTY 

LABOR 

LABOR 

MATL 

UNIT 

DAYS 

MONEY 

MONEY 

COST 

FF  1038 

PH 

75BDGT 

18346 

2139 

339 

2578 

FF  1047 

C 

75BDGT 

38426 

4954 

761 

5715 

FF  1059 

PH 

75BDGT 

38322 

4572 

754 

5325 

FF  1072 

C 

75BDGT 

37602 

4348 

760 

5608 

FFG  5 

PH 

75BDGT 

47576 

5676 

829 

6505 

FFG  6 

C 

75BDGT 

48250 

6221 

837 

7038 

»»##AVERAGE*»* 

38087  4743  722  5462 


( i 

! ^ 

I 1 
! I 

r } 


I 
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kl 
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WOULD  YOU  LIKE  TO  SUBMIT  ANOTHER  QUERY?-  YES 
PLEASE  INPUT  QUERY  COMMANDS 
QUERY  #X2 

IF  PREFIX  HULL  IS  DE  OR  FF  AND 
FNDACTUTY  IS  74BDGT  AND 
PREFIX  FCLTY  IS  BE  TO  A/Z? 

REPORT  *1 

i SORT  ON  HULL 

! PRINT  AVERAGE  BDGTLDAYSf  BDGTLMNYt  BDGTMNY 

[ PRINT  AVERAGE  BDGTLDAYS.  BDGTLMNY » BDGTMMNYr  BDGTUC03T 

I HEAD  1 4DE  AND  FF  APPORTIONMENT  FOR  FISCAL  74* 

f HEAD  2 *ALPHABETIC  YARDS  ONLY* 

IF  PREFIX  HULL  IS  DE  OR  FF  AND 
FNDACTVTY  IS  73BDGT  AND 
PREFIX  FCLTY  IS  BE  TO  (3/9? 

REPORT  *1 
SORT  ON  HULL 

HEAD  1 »DE  AND  FF  APPORTIONMENT  FOR  FIDCAL  75* 

HEAD  2 *NUMERIC  YARDS  ONLY* 

PRINT  AVERAGE » 

PRINT  AVERAGE  BDGTLDAYS.  BDGTLMNY . BDGTMMNY . BDGTUCOST 
I *END 


YOUR  QUERY  HAS  BEEN  ACCEPTED 


FOR  EACH  QUESTION.  TYPE  IN  D.  T.  OR  B. 


1 QUERY 

*X2. 

QUESTION 

NO. 

1 . HAS 

2 

HITS-T 

' QUERY 

*X2. 

QUESTION 

NO. 

2.  HAS 

0 

HITS  T 

f i 


X 

I 


? 1 


f ; ; 

Hi 

. i ■ 


453 


w 


AVERAGE  COST  OF  OVERHAUL 
DE  AND  FF  APPORTIONMENT  FOR  FISCAL  74 
ALPHABETIC  YARDS  ONLY 


REPORT  *1 


*X2001 


DEC  29  1975 


HULL 

YARD 

FND 

ACTVTY 

BDGT 

LABOR 

DAYS 

BDGT 

LABOR 

MONEY 

BDGT 

MATL 

MONEY 

BDGT 

UNIT 

COST 

FF  1049 

C 

74BDGT 

21319 

2601 

542 

3143 

FF  1056 

PH 

74BDGT 

21051 

2337 

422 

2759 

*#**average*»* 

21135 


2469 


482 


2951 


WOULD  YOU  LIKE  TO  SUBMIT  ANOTHER  QUERY?- 


PLEASE  ANSWER  YES  OR  NO-  YES 


PLEASE  INPUT  QUERY  COMMANDS 
QUERY  *X3 

IF  ASOFDATE  IS  75<363<3  AND  ENDATE  IS  LE  TO 

IF  ASOFDATE  IS  750630  AND  PREFIX  ENDATE  IS  LE  TO  7506  AND 

PREFIX  HULL  IS  DE  OR  FF  AND 

PREFIX  FCLTY  IS  BE  TO  0/9? 

REPORT  *2 

SORT  ON  HULL 

PRINT  AVERAGE  TOTFND 

HEAD  1 4DE  AND  FF  CLASS  SHIPS* 

HEAD  2 ^NUMERIC  YARDS  ONLY* 

IF  ASOFDATE  IS  750630  AND  ENDATE  IS  LE  TO  7506  AND 
PREFIX  HULL  IS  LST  AND 
PREFIX  FCLTY  IS  BE  TO  0/9? 

REPORT  *2 
SORT  ON  HULL 
PRINT  AVERAGE  TOTFND 
HEAD  1 *LST  CLASS  SHIPS* 

HEAD  2 *AVERAGE  OVERHAUL  COST  FOR  FISCAL  75* 

HEAD  3 *NUMERIC  YARDS  ONLY* 

IF  ASOFDATE  IS  750630  AND  ENDATE  IS  LE 

’/.A 


USER  ABORT 

QUERY  RUN  ABORTED  IN  ROUTINE  LT 

WOULD  YOU  LIKE  TO  SUBMIT  ANOTHER  QUERY’’- 
SI3  ERROR  RECOVERY 
FOLLOWING  FILES  TO  BE  CLOSED  BY  SIS 
RECOVERY- 

REPDEF3 

YES 


] 

9: 


i 


s 


r * 


PLEASE  INPUT  QUERY  COMMANDS 
QUERY  *X3 

IF  A30FUATE  13  75U630  AND  PREFIX  ENDATE  IS  LE  TO  7536  AND 
PREFIX  HULL  13  DE  OR  FF  AND 
PREFIX  FCLTY  IS  BE  TO  0/9? 

REPORT  *2 

SORT  ON  HULL 

PRINT  AVERAGE  TOTFND 

HEAD  1 »DE  AND  FF  CLASS  SHIPS* 

HEAD  2 ^AVERAGE  OVERHAUL  COST  FOR  FISCAL  75* 

HEAD  3 *NUMERIC  YARDS  ONLY* 

IF  A30FDATE  IS  750630  AND  PREFIX  ENDATE  IS  LE  TO  7506  AND 
PREFIX  HULL  IS  DE  OR  FF  AND 
PREFIX  FCLTY  IS  BE  TO  A/Z? 

REPORT  *2 

SORT  ON  HULL 

PRINT  AVERAGE  TOTFND 

HEAD  1 *DE  AND  FF  CLASS  SHIPS* 

HEAD  2 *AVERAGE  OVERHAUL  COST  FOR  FISCAL  75* 

HEAD  3 *APLPHABETIC  YARDS  ONLY* 

IF  A30FDATE  IS  750630  AND  PREFIX  ENDATE  IS  LE  TO  7506  AND 
PREFIX  HULL  IS  LST  AND 
PREFIX  FCLTY  IS  BE  TO  0/9? 

REPORT  *2 
SORT  ON  HULL 
PRINT  ASVERAGE 
PRINT  AVERAGE  TOTFND 
HEAD  1 *L3T  CLASS  SHIP* 

HEAD  2 *AVERAGE  OVERHAUL  COST  FOR  FISCAL  75* 

HEAD  3 *NUMERIC  YARDS  ONLY* 

IF  ASOFDATE  IS  750630  AND  PREFIX  ENDATE  IS  LE  TO  7506  AND 
PREFIX  HULL  IS  LST  AND 
PREFIX  FCLTv  ISBE  TO  A/Z? 

REPORT  *2 

SORT  ON  HULrL 

SORT  ON  HULL 

PRINT  AVERAGE  TOTFND 

HEAD  1 *LST  CLASS  SHIPS* 

HEAD  2 *AVERAGE  OVERHAUL  COST  FOR  FISCAL  75* 

HEAD  3 *ALPHABETIC  YARDS  ONLY* 

*END 

YOUR  QUERY  HAS  BEEN  ACCEPTED 


FOR  EACH  QUESTION.  TYPE  IN  D.  T.  OR  B. 


QUERY 

»X3. 

QUESTION 

NO. 

1 f 

HAS 

0 

HITS 

QUERY 

*X3. 

QUESTION 

NO. 

2. 

HAS 

1 

HITS-T 

QUERY 

*X3. 

QUESTION 

NO. 

3. 

HAS 

0 

HITS 

QUERY 

»X3r 

QUESTION 

NO. 

4. 

HAS 

0 

HITS  T 

t 

i'. 
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AVERAGE  COST  OF  OVERHAUL 


t 


DE  AND  FF  CLASS  SHIPS 


AVERAGE 

OVERHAUL 

COST  FOR  FISCAL 

75 

ALPHABETIC 

YARDS  ONLY 

REPORT  *2 

♦X3002 

DEC  29  1975 

HULL 

YARD 

FND 

END 

TOTAL 

PERCNT 

ACTVTY 

DATE 

FNDG 

OVHL 

FF  1049 

C 

75C0R 

APR  75 

4949 

100 

♦♦♦•AVERAGE*** 


■ i 


457 


! 


NSRDC  6700  INTERCOM  V4.2 
DATE  12/30/75 
TIME  14.08.41. 

PLEASE  LOGIN 

LOGINrPlJWEWEAVER,  1 180600323  f SUP 
COMMAND-  ETLi500 
COMMAND-  COMRADE f SHARP 


COMRADE  time:  14.09.38. 

DATE!  12/30/75 

SHARP  SUBSYSTEM  ENTERED 
????  IQUERY 


YOU  HAVE  SELECTED  THE  INTERACTIVE  QUERY  OPTION. 
WOULD  YOU  LIKE  AN  EXPLANATION  OF  THE  SYSTEM7-NO 


SELECT  ONE  OF  THE  FOLLOWING  DATA  BASES 
13  LOGISTICS  DOCUMENT  DATA  BANK 

31  YURSO  DATA  BANK 

32  MKRS-BASE-2 
??  32 


PLEASE  INPUT  QUERY  COMMANDS 
QUERY  QT 

IF  PREFIX  HULL  IS  LST  AND 
FNDACTVTY  IS  75BDGT  AND 
PREFIX  FCLTY  IS  BE  TO  0/9? 

REPORT  •! 

SORT  ON  HULL 

PRINT  AVERAGE  BUGTLDAYSf  BDGTLMNY f BDGTMMNYt  BGDGTUCOST 
HEAD  1 'tLST  APPORTIONMENT  - FISCAL  75* 

HEAD  2 *NUMERIC  YARDS  ONLY* 

♦ END 

YOUR  QUERY  HAS  BEEN  AC  i^PTED 


FOR  EACH  QUEST  I ON r TYPE  IN  Di  Tt  OR  B. 

QUERY  QT  t raUESTION  NO.  1,  HAS  1 HITS-T 
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AVERAGE  COST  OF  OVERHAUL 


LST  APPORTIONMENT  - FISCAL  75 
NUMERIC  YARDS  ONLY 


REPORT  *1  QT  001 


HULL 

YARD 

FND 

ACTVTY 

BDGT 

LABOR 

DAYS 

BDGT 

LABOR 

MONEY 

BDGT 

MATL 

MONEY 

LST  1170 

5 

75BDGT 

3292 

778 

**»*AVERAGE**» 

» 


773 


30  1975 

BDGT 

UNIT 

COST 

4070 


3292 


4070 


WOULD  YOU  LIKE  TO  SUBMIT  ANOTHER  QUERY?-  YES  | 

PLEASE  INPUT  QUERY  COMMANDS  | 

QUERY  TWX  j 

IF  PREFIX  RCDID  IS  411?  ■< 

HEAD  1 *3HARP  QUERY*  I 

HEAD  2 *INTEGRATION  OF  THE  DATA  BASE/COMMUNICATIONS  FUNCTION*  ‘ 

HEAD  3 *FLEXIBILITY  OF  THE  SPLIT-PHASE  KEY* 

*END  ■ 

YOUR  QUERY  HAS  BEEN  ACCEPTED 


FOR  EACH  QUEST  ION t TYPE  IN  Dt  Tf  OR  B. 

QUERY  TWX.  QUESTION  NO.  1.  HAS  2 HITS-T 


SHARP  QUERY 


INTEGRATION  OF  THE  DATA  BASE/COMMUNICATIONS  FUNCTION 


FLEXIBILITY  OF  THE  SPLIT-PHASE  KEY 


REPORT  DFT  TWX001 


DEC  30  1975 


PROC/DATE:  750702 
RCDID:  411010001 

TWX:  SHARP  WILL  YOU  CHECK  UPDATE? 


PROC/DATE:  750710 
RCDID:  411020002 

TWX:  WEAVER/SHARP  REFERENCE  YOUR  MESSAGE  411010001.  UPDATE  IS 

OPERATIONAL,  YOUR  TWX  HAS  BEEN  RECEIVED  HERE  AT  NSRDC.  NEW  SUBJECT; 
REGARDING  THE  QUERY  TO  RETRIEVE  SUBMARIMESi  I MAY  HAVE  GIVEN  CHUCK  THE 
WRONG  ACRONYM  TO  BE  USED  FOR  THE  NC  VALUE.  IF  I GAVE  HIM  OVHLACTVTY  IN 
WRITING  ON  THE  PRINTOUT.  IT  WAS  WRONG.  INSTEAD  OF  USING  FIELD  35  I 
SUGGEST  YOU  USE  FIELD  37  WHICH  IS  TYPEOVHL  I.E.  AND  TYPEOVHL  IS  NC?  NO 
HITS  ON  THAT  ONE  BUT  IF  YOU  TRY  ONE  THAT  YOU  KNOW  IS  IN  THERE  IT  SHOULD 
WORK,  I HAVE  OBTAINE  CORRECT  RESULTS  ON  THAT  QUERY  HERE  AT  THE  NSRDC 
SITE.  EOM 
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1 CHONR  (Mr.  Dennicoff) 
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